Struct Initialization syntax

[Jim Balter]

On Tuesday, 24 July 2018 at 16:35:32 UTC, H. S. Teoh wrote:
> On Tue, Jul 24, 2018 at 01:13:16PM +0000, Dukc via 
> Digitalmars-d wrote:
>> On Tuesday, 24 July 2018 at 12:37:21 UTC, Cym13 wrote:
>> > That argument sounds quite dangerous to me, especially since 
>> > my experience is on the contrary that constructor arguments 
>> > are often named the same as the attribute they refer to. And 
>> > what of mixed cases? I really wouldn't rely on anything like 
>> > naming conventions for something like that.
>> 
>> I was going to ask that how can they be named the same since 
>> the argument would then shadow the member, but then I realized 
>> that this works:
>> 
>> struct S
>> {   int a;
>>     int b;
>> 
>>     this(int a, int b)
>>     {   this.a = a;
>>         this.b = b;
>>     }
>> }
>> 
>> Yes, you are right.
>
> It works, but TBH it's quite a bad idea, and very confusing to 
> read.

This is a very common programming style and is found in numerous 
programming books and tutorials. Personal judgments as to whether 
it's a good idea or confusing are completely beside the point; 
designers of struct initialization syntax should not impose such 
judgments on the rest of the world, possibly forcing people to 
change their code and their texts.

> And TBH, if all the ctor is doing is copying its arguments to 
> member variables, then we really should be more DRY and have 
> special syntax for doing that, ala C++ (though the C++ syntax 
> itself is pretty pathological... D could use better syntax, but 
> the idea remains: get rid of redundancy like `this.a = a` or `a 
> = _a`).
>
>
> T

This too is completely off topic. And there are hundreds of 
thousands of extant lines of such code in various languages other 
than C++ (or Scala, which has a different and more concise way to 
avoid this boilerplate), and it hasn't been a big deal. Some 
people use IDE forms/macros to fill in these common lines.

Back to the topic: I think #1 is noisy and confusing -- it looks 
like a function or ctor call but isn't, and it looks like {...} 
is a literal but isn't. I think #2 has to be considered in 
conjunction with and dependent on named parameters. If named 
parameters use the same syntax then #2 could be treated as if it 
were a call to an implicit ctor that takes optional named 
parameters corresponding to each member, which would provide 
uniformity, but I think it's a bit dangerous and confusing, using 
the same syntax to do two different things, initialization and 
construction. I think #3 is straightforward, clear, and 
consistent with existing struct initialization ... does it have 
any downsides?