Syntax sugar for {} with structs

[Paul Backus]

On Friday, 1 July 2022 at 18:21:01 UTC, ryuukk_ wrote:
> Of course i can write the template, of course i could write a 
> function in the struct
>
> If i came to write the thread is to talk about the feature 
> idea, not what function i can write
>
> Suggesting me to write a function is implying i didn't think 
> about it beforehand, wich is a little bit rude

I can't read your mind, so I don't know what you thought about 
beforehand or what you wrote this thread to talk about. I only 
know what you actually wrote in your post.

> i got the same kind of answers about the .Enum, wich is 
> unfortunate that people can't focus on talking about the 
> feature instead of telling people to do what they were already 
> doing and to not bother trying

I gave [a detailed response][1] to the enum proposal the first 
time it came up, back in December.

This proposal has essentially the same issues as that one, which 
is that the expression `{}` would be ambiguous in many contexts. 
For example:

```d
struct A {}
struct B {}

void f(A) {}
void f(B) {}

f({}); // ambiguous

void g(A) {}
void g(int) {}

g({}); // not ambiguous, but potentially confusing

void h(A, B) {}

h({}, {}); // not ambiguous, but potentially confusing
```

The obvious solution is to make ambiguous usage a compile-time 
error. However, even if you do that, there are still the 
unambiguous-but-confusing cases to deal with.

Another solution is to narrow the scope of the proposal, and just 
make `= {}` a special-case syntax for assignment, without 
allowing the use of `{}` anywhere else. The problem with this 
proposal is that you can get exactly the same result using the 
utility function, so the benefits are probably not high enough to 
outweigh the fixed costs of adding a new language feature.

[1]: 
https://forum.dlang.org/post/zggvaorhdkijuwegmtpz@forum.dlang.org