Enum literals, good? bad? what do you think?

Petar Petar
Wed Jul 21 15:13:36 UTC 2021

On Tuesday, 20 July 2021 at 16:34:13 UTC, Paul Backus wrote:
> On Tuesday, 20 July 2021 at 15:50:49 UTC, russhy wrote:
>> So what do you think? yay? nay? why not?
>> [1] https://github.com/RUSshy/DIPs/blob/patch-2/DIPs/DIP1xxx.md
> Currently, name lookup in D is done independently from 
> type-checking. This proposal would require name lookup to 
> depend on type checking in order to compile code like the 
> following example:
> ```d
> enum A { x }
> enum B { x }
> A var = .x;
> ```

One could argue that function overloading is a case where name 
resolution already depends on type checking. In a sense, `x` (in 
the above snippet) would be an overloaded name, which can 
resolved in a given context.

Note that the question of overloading manifest constants was 
raised when the first-class function [DIP][1] was active. If that 
DIP is revisited, the question would need to be resolved.

> I don't think adding this kind of complexity to the language 
> semantics is worth it just to save a few characters.

I don't mind keeping D simpler, but I want to point out that the 
complexity depends on the scope of the feature.

Function calls are likely harder to implement due to overloading, 
based on the comment [here][2], but target-typed variable 
initialization and assignment is likely more straightforward.

OTOH, allowing target-typed literals in one place (variable init 
/ assignment) and not in other (function calls) could be regarded 
as a pointless and artificial design limitation (similar to how 
struct literals are allowed only for [variable 
That could be the reason why C#'s language team decided to allow 
target-typed `new` expressions in both contexts with C# 9:


[2]: https://issues.dlang.org/show_bug.cgi?id=16437#c2
[3]: https://dlang.org/spec/struct#static_struct_init

More information about the Digitalmars-d mailing list