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.

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.

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

-- 
Старый друг лучше новых двух.

On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
> I personally prefer option 2, but this might be in conflict to named arguments which we hopefully see in the near future too. Hence, I'm leaning forward to proposing Option 1 as the recommended Option for the DIP (that's also what the PoC DMD PR implements). What's your take on this?

If we have named arguments that can be reordered and, when they have default values, omitted, we don't really need a special struct initialization syntax. We just need the compiler to generate the implicit struct constructor in the obvious way, like:

struct S
{
  string a = "field a!";
  int b = 10;
  // compiler-generated
  this(<string a = "field a!", int b = 10>) {...}
}
writeln(S(a: "hello", b: 15));

Similarly, struct initializer syntax everywhere slightly reduces the need for named arguments, albeit with some inconvenience:

// named args style
void drawRect(<int x, int y, int width, int height, string color>) {}
// struct style
struct DrawRect
{
  int x, y, width, height;
  string color;
}
void drawRect(DrawRect rect) {}

On 25/07/2018 5:55 AM, Neia Neutuladh wrote:
> 
> Similarly, struct initializer syntax everywhere slightly reduces the need for named arguments, albeit with some inconvenience:

It actually doesn't surprisingly.
As long as you support it for templates as well.
At which point it creates a nice consistent experience.

On Monday, 23 July 2018 at 18:31:03 UTC, John Colvin wrote:
> On Monday, 23 July 2018 at 16:57:20 UTC, H. S. Teoh wrote:
>> On Mon, Jul 23, 2018 at 04:26:42PM +0000, Seb via Digitalmars-d wrote:
>>> tl;dr: the currently proposed syntax options are:
>>> ---
>>> struct S
>>> {
>>>     int a = 2, b = 4, c = 6;
>>> }
>>> void foo()
>>> {
>>>     bar(S({c: 10})); // Option 1
>>>     bar(S(c: 10));   // Option 2
>>>     bar(S{c: 10});   // Option 3
>>> }
>
> ...
>
> Seeing as we already have
>
> S s = { c : 10 };
>
> I'd say it would be fairer to say it resembles anonymous function syntax and AA initialisation syntax, but mostly it resembles the existing struct initialisation syntax.

Not sure about this, but wouldn't

    bar({c: 10});

be consistent with

   S s = { c : 10 };

?

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?