C lib constants and Enum members currently don't allow leading underscores

[Hadeweka]

Discussion

What aspect of the language would you like to see improved?

Currently. lib constants and C Enums do not allow the members to start with anything than an uppercase letter - while this is completely legal in C code. For better compatibility, it would be helpful to allow leading underscores in these specific scenarios.

What are the reasons?

See example below.

I currently see no conceptual reason to forbid underscores in C binding constants, as there are no local variables in allowed in lib expressions anyway. Path expressions like Foo::_Bar are also currently not allowed, so this should not break existing code.

Include practical examples to illustrate your points.

One example would be bindings for SDL_gpu (for SDL3). The original code has an enum like this:

typedef enum SDL_GPUTextureType { 
  SDL_GPU_TEXTURETYPE_2D,
  SDL_GPU_TEXTURETYPE_2D_ARRAY,
  SDL_GPU_TEXTURETYPE_3D,
  SDL_GPU_TEXTURETYPE_CUBE,
  SDL_GPU_TEXTURETYPE_CUBE_ARRAY
} SDL_GPUTextureType;

Ideally, one would create a new lib and an enum:

lib SDL
  enum GPUTextureType
    2D
    2D_Array
    3D
    CUBE
    CUBE_ARRAY
  end
end

However, this leads to the obvious problem that 2D, 2D_ARRAY and such would start with a numeric literal. One can either keep the original names like SDL::GPUTextureType::SDL_GPU_TEXTURETYPE_2D_ARRAY, which would lead to unnecessarily verbose code that is hard to read.

Alternatively (and this is, for example, specifically done in the Rust bindings for SDL3), the numeric literals could be changed from 2D_ARRAY to _2D_ARRAY. This is currently not possible. There is always additional verbosity necessary to get the values to work in the first place.

Optionally add one (or more) proposals to improve the current situation.

Parse the names for regular Crystal constants and C lib constants differently. At least allow the underscore character for C lib and C Enum constants, where they pose no ambiguity (and several declarations work different from regular Crystal code anyway).

[oprypin]

I think the inconsistency that this would introduce into the language is unresolvable.

Foo is guaranteed to mean a constant and _Foo is guaranteed to mean a method or variable access.

This code currently is valid:

enum Items
  Foo
  
  def self.test
    p Foo
  end
  
  def self._Foo
    puts "method"
  end
end
 
Items.test
 
Items._Foo

Imagine that your suggestion is implemented and we write _Foo everywhere instead of Foo in the code above. What should happen?

[oprypin]

There would definitely be weirdness in making this happen:
When seeing Foo, the compiler knows it needs to look only among constants, and for _Foo to look only among non-constants.
With this suggestion, _Foo would become a unique situation where the compiler needs to look at both. And there would also need to be an additional new check for preventing a constant and a method being named the same, only for this unique case

[straight-shoota]

I suppose we could rephrase the issue as looking for a good solution to spell constants that naturally start with a non-uppercase character.

[Hadeweka]

I suppose we could rephrase the issue as looking for a good solution to spell constants that naturally start with a non-uppercase character.

I could see that, too, however I have no other good suggestion yet.