February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert M. Münch | 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.
|
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert M. Münch | 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 |
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | 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
|
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | 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? |
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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?
|
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | 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.
|
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to IGotD- | 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
|
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | 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 |
February 13, 2020 Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion | ||||
---|---|---|---|---|
| ||||
Posted in reply to IGotD- | 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.
|
Copyright © 1999-2021 by the D Language Foundation