Remove circle/diamond String constants

[akien-mga]

They were introduced in #14704 but need more discussion IMO, they don't strike me as core features that would have to be registered in Variant directly.

What was approved in #14704 was mostly the way the new built-in constants were implemented, but the actual list of constants was not thoroughly reviewed. I'm not against adding constants to String but those 4 seem quite arbitrary to me, and set a precedent for "please add a constant for <insert favourite Unicode emoji here>" feature requests.

[akien-mga]

Also removed the NodePath built-in constants as they broke documentation too, as they were encoded as invalid XML:

        <constants>
              <constant name="CURRENT" value=""."">
              </constant>
              <constant name="PARENT" value="".."">
              </constant>
        </constants>

I also don't see much use case for them, so it seems fine to remove for now, and reintroduce only if proven consensual and not breaking documentation.

[KellyThomas]

While discussing this collection of constants I would like to know if people are happy with X, Y, Z in Plane.

The names have two issues I see:

1. they may be confused with the instance fields x, y,z
2. they refer to values I would normally think of as the YZPlane, XZPlane and XYPlane respectively.

Edit: I'm not sure how strongly this needs to be considered but the first point becomes a problem when porting to c# where the instance properties should be PascalCase. Given that we have an ecosystem with more than one language I encourage not choosing names that differ only by case.

[aaronfranke]

@KellyThomas A better name would be PlaneXY etc. I'd prefer to keep the two letters on the right.

EDIT: #21253

[KellyThomas]

Another name clash occurs between the member function Color.gray() and the constant Color.gray.

In GDScript this seems to resolve correctly but will cause issues in languages like c# where static and instance members can't share a common name.

[akien-mga]

That Color.gray() function seems pretty useless, I'd be for removing it altogether when we can. Averaging R, G and B values does give a "grey" color, but it's hardly meaningful, a proper greyscale would use one of those methods: https://en.wikipedia.org/wiki/Grayscale#Converting_color_to_grayscale

[akien-mga]

That Color.gray() function seems pretty useless, I'd be for removing it altogether when we can. Averaging R, G and B values does give a "grey" color, but it's hardly meaningful, a proper greyscale would use one of those methods: https://en.wikipedia.org/wiki/Grayscale#Converting_color_to_grayscale

I'll see with @reduz if we can rename it to to_grayscale() and use a proper conversion for that. Then C# could use ToGrayscale(), and we'd keep gray() as deprecated method only for GDScript.

[vnen]

In GDScript this seems to resolve correctly but will cause issues in languages like c# where static and instance members can't share a common name.

GDScript will have this same restriction in the future, so it's really important to avoid these conflicts. Maybe even embed it in the bindings to generate a compilation error if it happens.

[akien-mga]

See #21267 for the Color::gray() issue.