Type Inference for Struct/Enum Literals

IchorDev zxinsworld at gmail.com
Mon Jul 22 03:51:45 UTC 2024


On Monday, 22 July 2024 at 01:17:19 UTC, harakim wrote:
> I like the syntax of  not prefix.
> [...]
> Why do you not like the prefixless solution?

You might want to preview how your reply looks before sending it. 
I had to manually reverse-engineer which parts of your message 
were your response…

Having no prefix is less explicit, making it harder to read code 
that uses the feature.
```d
struct S{ int a, b, c; }
S s = (a, b, c);
```
Comma expression in parenthesis? Nope, it's secretly a 
constructor. This same problem applies to enums:
```d
enum E{ a,b,c }
int a, b, c;
someFunction(a); //what is `a`?
```
So now we have two names in the same scope that shadow 
each-other. How do we get around this? Module scope operator?
```d
enum E{ a,b,c }
int a, b, c;
someFunction(.a); //both versions of `a` are in the same 
scope—still ambiguous
```
No, ultimately this is the same stupid problem that C has. If you 
want enums that work like this, just write them like this:
```d
enum { a=0,b=1,c=2 }
```
Or use a mixin to expand them.
Also this syntax is inconsistent with how the rest of D works. 
Would you apply this logic to the members of a struct? It would 
certainly be logically consistent to do so:
```d
struct S{ int a, b, c; }
enum E{ a,b,c }
S s = (a, b, c);
someFunction(a); //could be `s.a` or `E.a` depending on 
`someFunction`'s signature
```


More information about the dip.ideas mailing list