Remove operators for color

[protonspring]

This is a non-functional and untested simplification. The increment operator for color isn't really necessary and seems a bit unnatural to me.

[snicolet]

This needs some test to check that there is not speed penalty, depending on what code the compiler emits for the alternate form..

[protonspring]

I tried to use godbolt, but the compiler doesn't seem to recognize the new form.

Are you wanting a -3,1 test on the framework, or godbolt code?

[Sopel97]

https://godbolt.org/z/XmG1wL
tldr: if you don't care about msvc then it's the same codegen. clang has stupidly high limit on unrolling so pretty much no problem

[snicolet]

A -3,1 test in the framework would be fine

[Rocky640]

@protonspring
Before running a [-3, 1] test, while being there, can you also prettify the following line
for (CastlingSide s = KING_SIDE; s <= QUEEN_SIDE; s = CastlingSide(s + 1))
for
for (CastlingSide s : { KING_SIDE, QUEEN_SIDE })

[protonspring]

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 47027 W: 10589 L: 10518 D: 25920
http://tests.stockfishchess.org/tests/view/5d3472d10ebc5925cf0e8d3e

[snicolet]

Could we retest the PR version in isolation? thanks :-)

[protonspring]

@snicolet I'm not sure what you're asking for. You want a -3,1 test without Rocky's addition?

[Rocky640]

The proposed change to CastlingSide in bool function pos_is_ok is harmless.
pos_is_ok is only called in debug mode and inside some assert calls

[snicolet]

@protonspring @Rocky640
I was confused when I saw the commit "single kingSquares", which was not intented to be part of the pull request if I understand correctly. I am fine with the changes for Color and CastlingSide, which is indeed not in the critical path of SF.

[snicolet]

Merged via aec918a

[Rocky640]

@snicolet That was busy day !