The strongly-typed enum groups which were "standardised" in #335 and have been heavily iterated upon for correctness since are garnering more use as time goes on. Google (for ANGLE) and Arm (for a debugging/API trace tool: more info).
Given Khronos do not use the group information directly themselves, they have often gone forgotten about and whatever a incoming community contribution says, goes. I think given the increasing importance of these groups we should be wary of breaking changes.
In bindings generated from the gl.xml, the groups may be used to define more friendly API signatures. A good example from the Silk.NET library can be found here. By changing group information in gl.xml, this causes a break in that library. We have come to accept this, but it's important Khronos knows that implication.
One core tenet of the groups is correctness. They exist to provide information on what enums are valid for a particular parameter. As such, I do think we need some way of changing a parameter to a more correct one but how this looks from a breaking change policy perspective, I don't know. The thing is no group change, even if we did use enum { ... }s in C, would be breaking due to how C works.
But yeah, this issue mostly serves as a discussion as I don't know what a good (or any) solution is to this.
Thoughts?
The strongly-typed enum groups which were "standardised" in #335 and have been heavily iterated upon for correctness since are garnering more use as time goes on. Google (for ANGLE) and Arm (for a debugging/API trace tool: more info).
Given Khronos do not use the group information directly themselves, they have often gone forgotten about and whatever a incoming community contribution says, goes. I think given the increasing importance of these groups we should be wary of breaking changes.
In bindings generated from the gl.xml, the groups may be used to define more friendly API signatures. A good example from the Silk.NET library can be found here. By changing group information in gl.xml, this causes a break in that library. We have come to accept this, but it's important Khronos knows that implication.
One core tenet of the groups is correctness. They exist to provide information on what enums are valid for a particular parameter. As such, I do think we need some way of changing a parameter to a more correct one but how this looks from a breaking change policy perspective, I don't know. The thing is no group change, even if we did use
enum { ... }s in C, would be breaking due to how C works.But yeah, this issue mostly serves as a discussion as I don't know what a good (or any) solution is to this.
Thoughts?