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