On 2020-02-13 09:56:27 +0000, Walter Bright said:

> On 2/13/2020 1:47 AM, IGotD- wrote:
>> However, would
>> 
>> S s = (1, 2);
>> 
>> be allowed inferring the type?
> 
> No. But you can write:
> 
>    auto s = S(1, 2);

I never understood (but expect some good reason to exists) why I can't write:

S s(1,2);

which IMO is the most compact and clear form.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Thursday, 13 February 2020 at 11:04:26 UTC, Robert M. Münch wrote:
> I never understood (but expect some good reason to exists) why I can't write:
>
> S s(1,2);

It would only work in the context of a declaration, otherwise it's a CallExpression.

On Thursday, 13 February 2020 at 11:04:26 UTC, Robert M. Münch wrote:
> On 2020-02-13 09:56:27 +0000, Walter Bright said:
>
>> On 2/13/2020 1:47 AM, IGotD- wrote:
>>> However, would
>>> 
>>> S s = (1, 2);
>>> 
>>> be allowed inferring the type?
>> 
>> No. But you can write:
>> 
>>    auto s = S(1, 2);
>
> I never understood (but expect some good reason to exists) why I can't write:
>
> S s(1,2);
>
> which IMO is the most compact and clear form.

https://en.wikipedia.org/wiki/Most_vexing_parse

On 2/13/20 4:59 AM, Mike Parker wrote:
> On Thursday, 13 February 2020 at 09:56:27 UTC, Walter Bright wrote:
>>
>>> Would there be case where this type of initialization would mask the constructor of a type or vice versa?
>>
>> The constructor takes precedence.
>>
>>> struct S
>>> {
>>>      int a, b;
>>>      this(int bp, int ap)
>>>      {
>>>          a = ap;
>>>          b = bp;
>>>      }
>>> }
>>>
>>> writing
>>>
>>> S s = S(1, 2);
>>>
>>> what would it pick?
>>
>> The constructor.
> 
> Which, for the record, is the current behavior. Unfortunately, the struct literal documentation only mentions opCall. I'll submit a PR.
> 
> https://dlang.org/spec/struct.html#struct-literal

That page is *really* old. I think what Mike meant to say is that struct initializers and struct literals are both disabled once a constructor or opCall function is present.

So in essence, the above struct S could NEVER be initialized except via constructor or with it's .init value. Having the named parameter DIP accepted means that now the constructor becomes possible to call like the initializer, assuming you gave bp and ap default values.

-Steve

On Thursday, 13 February 2020 at 07:29:00 UTC, Mike Parker wrote:
> ...

Well first I'm not against this, but one thing that called my attention is that a while ago Manu proposed a DIP which was rejected (https://github.com/dlang/DIPs/blob/c0c1c9f9665e0bc1db611f4e93e793d64451f763/DIPs/rejected/DIP1016.md)

In that case Walter/Andrei bashed that DIP for lack of rationale/description/cases and so on.

I remember Andrei telling in this Forum, how a DIP should be written and he asked for a professional analysis and so on.

Now this DIP is very thin (I think it couldn't fill a A4 paper) and I'm seeing this trending in every Walter's DIP.

I mean the example shouldn't be set from they?

On Thursday, 13 February 2020 at 13:05:19 UTC, Steven Schveighoffer wrote:
>
> That page is *really* old. I think what Mike meant to say is that struct initializers and struct literals are both disabled once a constructor or opCall function is present.
>
> So in essence, the above struct S could NEVER be initialized except via constructor or with it's .init value. Having the named parameter DIP accepted means that now the constructor becomes possible to call like the initializer, assuming you gave bp and ap default values.
>
> -Steve

Isn't that a bit restrictive? Wouldn't you like to have a constructor and sometimes parenthesis style initialization? With using parenthesis for everything there will be an ambiguity. In that case keeping () for constructor and {} for initialization would make it clear what the programmer wants.

If the compiler cannot match a constructor it can go on and use initialization instead. Would this be too allowing and lead to that programmer errors are missed?

On Thursday, 13 February 2020 at 07:29:00 UTC, Mike Parker wrote:

> https://github.com/dlang/DIPs/blob/c0c1c9f9665e0bc1db611f4e93e793d64451f763/DIPs/DIP1031.md

If I understand correctly what this change means, I've already been using the 'new' way and didn't actually realize there was another way.

So... I see no problems here.

On 2/13/20 10:49 AM, IGotD- wrote:
> On Thursday, 13 February 2020 at 13:05:19 UTC, Steven Schveighoffer wrote:
>>
>> That page is *really* old. I think what Mike meant to say is that struct initializers and struct literals are both disabled once a constructor or opCall function is present.
>>
>> So in essence, the above struct S could NEVER be initialized except via constructor or with it's .init value. Having the named parameter DIP accepted means that now the constructor becomes possible to call like the initializer, assuming you gave bp and ap default values.
>>
> 
> Isn't that a bit restrictive? Wouldn't you like to have a constructor and sometimes parenthesis style initialization? With using parenthesis for everything there will be an ambiguity. In that case keeping () for constructor and {} for initialization would make it clear what the programmer wants.
> 
> If the compiler cannot match a constructor it can go on and use initialization instead. Would this be too allowing and lead to that programmer errors are missed?

You misunderstand.

{} intialization today does not work when a constructor is defined:

struct S
{
   int a;
   this(int a) {this.a = a; }
}

void main()
{
   S s = {a: 1};
}

Error: struct S has constructors, cannot use { initializers }, use S( initializers ) instead

So the only place this DIP would deprecate valid code is for structs without ctors.

-Steve

I'm against this change unless there's a good reason other than simplifying the language.

The brace-style struct initializers allow for beautiful code. This comment summarizes it well: https://github.com/dlang/DIPs/pull/169#issuecomment-532830320

On 2/13/2020 7:49 AM, IGotD- wrote:
> Isn't that a bit restrictive?

Yes, and it's on purpose. Note that this applies to C++ as well.

If all the constructor does is supply its arguments to the fields, there's not point in providing one. If it does more than that, by using literals the user could bypass that, which would be a clear code smell if not an outright bug. Worse, it would be difficult to QA the code as the constructor call would look just like an initializer.