You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Function overloading with an @enum type produces unexpected results #687
Emitting object aliases at type-scope like above at #687 (comment)
makes it possible for @enum and @flag_enum to have enumerators of the type of the enumeration.
But it would also makes all other uses of them in the signatures of members impossible.
Which I think is a much more common use case than having static data members of equal type.
For example, see ref-is-glvalue at https://eel.is/c++draft/range.join.iterator.
I view it as a bug that the enumerator doesn't have the type of the enumeration.
I think using functions to return the enumerator values would be better.
A Cpp1 enumerator is a platonic value.
A Cpp2 enumerator is an object alias.
But if Cpp2 enumerators were returned by a function,
they'd once again become platonic values.
Although there'd be more resistance to migrating to Cpp2's @enum from Cpp1's enum if you had to call enumerators to get the value.
And there's the chance of using the function pointer accidentally
(and ah, we'd have function(s) (pointers) in addition to the platonic values).
Perhaps it'd be better if Cpp2 simply treated type-scope object aliases with type equal to the type being defined specially
and they were lowered like #687 (comment).
Then we can all live happily.
Ack: Yes, I'm looking at this now. I always intended for enumerators to have the type of the enumeration, but Cpp1 doesn't allow that, so the initial implementation worked around it.
The solution I'm currently pursuing is to lower all type-scope object aliases as you suggest (see also https://stackoverflow.com/questions/11928089/), and then enumerators would Just Work too. That way I don't need to make enumerations a special case.
Activity
JohelEGP commentedon Sep 17, 2023
This was hinted at #131 (comment).
JohelEGP commentedon Sep 17, 2023
This formulation seems to permit having seemingly
static constexprdata members of the type being defined (https://compiler-explorer.com/z/7nY47a7YG):guybrush77 commentedon Sep 17, 2023
Thanks, I understand the underlying issue now.
Still, I hope that the ergonomics can be improved. I think the new @enum fails to adhere to the principle of least astonishment.
JohelEGP commentedon Sep 19, 2023
Emitting object aliases at type-scope like above at #687 (comment)
makes it possible for
@enumand@flag_enumto have enumerators of the type of the enumeration.But it would also makes all other uses of them in the signatures of members impossible.
Which I think is a much more common use case than having static data members of equal type.
For example, see
ref-is-glvalueat https://eel.is/c++draft/range.join.iterator.guybrush77 commentedon Sep 19, 2023
Right. I agree that using enums in signatures is a desirable feature.
Anyway, I will close this bug since it is not really a bug, but more like a design tradeoff.
JohelEGP commentedon Sep 19, 2023
I view it as a bug that the enumerator doesn't have the type of the enumeration.
I think using functions to return the enumerator values would be better.
A Cpp1 enumerator is a platonic value.
A Cpp2 enumerator is an object alias.
But if Cpp2 enumerators were returned by a function,
they'd once again become platonic values.
JohelEGP commentedon Sep 19, 2023
Although there'd be more resistance to migrating to Cpp2's
@enumfrom Cpp1'senumif you had to call enumerators to get the value.And there's the chance of using the function pointer accidentally
(and ah, we'd have function(s) (pointers) in addition to the platonic values).
Perhaps it'd be better if Cpp2 simply treated type-scope object aliases with type equal to the type being defined specially
and they were lowered like #687 (comment).
Then we can all live happily.
hsutter commentedon Sep 19, 2023
Ack: Yes, I'm looking at this now. I always intended for enumerators to have the type of the enumeration, but Cpp1 doesn't allow that, so the initial implementation worked around it.
The solution I'm currently pursuing is to lower all type-scope object aliases as you suggest (see also https://stackoverflow.com/questions/11928089/), and then enumerators would Just Work too. That way I don't need to make enumerations a special case.
hsutter commentedon Sep 22, 2023
I've now improved this in b589f5d
The original bug report code at top now prints
Invoked foo: (color: Color).The lowering is along the same lines mentioned by Johel and https://stackoverflow.com/questions/11928089/
Thanks!