Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On 4/18/22 09:17, Ali Çehreli wrote: > shared static ~this(): 0 > static ~this(): 0 >~this(): 8 Apologies for omitting 'scope' statements: scope(exit): 34 scope(success): 6 scope(failure): 8 Ali
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On 4/17/22 17:35, Ali Çehreli wrote: > compared to C++, the amount of constructor, destructor, copy > constructor, etc. that I do *not* write in D is very liberating to me. > It feels like I just write what is needed and it mostly just works. The following is a quick and dirty grep-based stats from a largish successful project that implements multiple libraries and binaries. The figures are numbers of times each construct appears in source code: struct: 231 interface: 3 class: 12 union: 0 this(/* ... */): 72 [1] shared static this(): 8 static this(): 1 [2] shared static ~this(): 0 static ~this(): 0 ~this(): 8 this(this): 0 [3] [1] Most operations in most constructors are trivial assignments to members. [2] It contains just an enforce expression to ensure the environment is as expected. (It is an oversight that this is not a 'shared static this' as well.) [3] There are no copy constructors either because the project started with an older compiler. It is remarkable that I did not implement a single copy or move behavior ever. Compare that to countless C++ articles on attempting to teach how to deal with fundamental operations of object. Forgotten to be called or not, there are no 'move' (which does not move in C++) or 'forward' (which does not forward in C++) expressions at all. What a price the programming community keeps on paying just because their powerful programming language was there first... Ali
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On Mon, Apr 18, 2022 at 08:22:26AM +, cc via Digitalmars-d-learn wrote: > On Monday, 18 April 2022 at 03:21:30 UTC, H. S. Teoh wrote: > > Structs in D ought to be treated like "glorified ints", as Andrei > > puts it. If you need complex ctors and complex methods, that's a > > sign you should be using a class instead. > > Unless you're having a nice quiet get-together with friends, and you > don't want to invite the GC, the biggest loudest party animal on the > block. Phobos's RefCounted seems to stretch the definition of > "glorified ints".. "Glorified int" includes pass-by-value types like pointers. Pointers / references wrapped in a struct is one of the more powerful D constructs that lets you do some pretty neat things. (Just don't expect it to behave like C++, lol. :-P) T -- Debian GNU/Linux: Cray on your desktop.
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On Monday, 18 April 2022 at 13:21:44 UTC, zjh wrote: I hope that d can support it like `C++`. `Struct` and `class` behavior is inconsistent. `Constructors` sometimes have initialize behavior. If D doesn't think about `C++` users, `C++` users feel too troublesome, can't understand, and the cognitive burden is too heavy.
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On Sunday, 17 April 2022 at 15:13:29 UTC, HuskyNator wrote: This is a twofold question, along the example code below: The `default constructor` of `struct` is very convenient to use. I hope that d can support it like `C++`.
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On Monday, 18 April 2022 at 10:26:16 UTC, HuskyNator wrote: On a sidenote, I'm surprised D did not choose 0 as the default floating value. Doesn't almost every language do this? I understand the thinking behind it, but when the type one uses in a template influences the behavior of the code, that seems like a pretty big red flag to me. (Any non-floating type defaults to 0, but using floats/doubles suddenly introduces NaN, surely I'm not the only one that sees a problem with this ) Especially when it's basically a standard 0 is used for this. Sorry for the rant. Let me explain the why: D default initialization is not designed to replace user-defined initialization, it's rather made to make bugs related to non-initialized variables stable, e.g not UB. The easiest way to get that is to think to references and pointers. A random garbage value pointed by an alloca may work to some point (e.g access to member), if it's set to `null` right after the alloca then you have a stable segfault that always happens at the same time and is easy to debug. Similarly, for floating point numbers the D designers considered that `NaN` was the best choice because FP operations will not wrongly appear valid when starting operations with NaN. With integral types, this system does not work as well, as `0` doesn't create bugs as easily as `null` and `NaN`. The confusion about the real role of default initialization comes from integral types I believe.
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On Monday, 18 April 2022 at 10:26:16 UTC, HuskyNator wrote: On a sidenote, I'm surprised D did not choose 0 as the default floating value. Doesn't almost every language do this? I understand the thinking behind it, but when the type one uses in a template influences the behavior of the code, that seems like a pretty big red flag to me. (Any non-floating type defaults to 0, but using floats/doubles suddenly introduces NaN, surely I'm not the only one that sees a problem with this ) Especially when it's basically a standard 0 is used for this. Sorry for the rant. I agree, it's a hiccup. I have at times intentionally initialized a float as NaN so that I can identify later whether an appropriate value has been assigned, but I've never seen the need to have this be the default behavior when integer types always init to 0 (more specifically, init to a MODIFYABLE value). In game design I have tons upon tons of floats that all [should] start initialized to zero. I can add 4 to a declared but not-assigned-to int and it'll be 4, a float remains NaN. Having to manually declare appropriate init values to each one doesn't aid me in detecting "bugs". If I had an int that was supposed to default to 10 instead of 0 it would still be a bug if I forgot to specify that, tripping me up for falsely assuming floats would start at 0 doesn't aid my workflow in any way. The whole "you should pay more attention to what you're initializing, o buggy programmer you" philosophy seems like something that should be reserved for pointers and reference types, not basic numeric data. It's probably set in stone by this point though and too late to change. Ten years ago, almost to the day: https://forum.dlang.org/thread/thsjtreegdwcgbazh...@forum.dlang.org The reasoning still feels flimsy and stubborn.
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On Monday, 18 April 2022 at 03:21:30 UTC, H. S. Teoh wrote: Structs in D ought to be treated like "glorified ints", as Andrei puts it. If you need complex ctors and complex methods, that's a sign you should be using a class instead. I prefer not to use classes, as the code would now move towards using references, which is the exact reason I'm using structs. I ended up creating a constructor for my needs and disabling the default constructor. I'm mostly just surprised the static syntax is turned off by adding one. I still don't see the reason behind it. Why have it but disable it? I ironically almost always need the exact same constructor with the identical arguments though: Initialize the matrix to the identity matrix. Why not introduce the empty self-defined constructor as a separate thing from the .init value? On a sidenote, I'm surprised D did not choose 0 as the default floating value. Doesn't almost every language do this? I understand the thinking behind it, but when the type one uses in a template influences the behavior of the code, that seems like a pretty big red flag to me. (Any non-floating type defaults to 0, but using floats/doubles suddenly introduces NaN, surely I'm not the only one that sees a problem with this ) Especially when it's basically a standard 0 is used for this. Sorry for the rant.
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On Monday, 18 April 2022 at 03:21:30 UTC, H. S. Teoh wrote: Structs in D ought to be treated like "glorified ints", as Andrei puts it. If you need complex ctors and complex methods, that's a sign you should be using a class instead. Unless you're having a nice quiet get-together with friends, and you don't want to invite the GC, the biggest loudest party animal on the block. Phobos's RefCounted seems to stretch the definition of "glorified ints"..
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On Sun, Apr 17, 2022 at 05:35:13PM -0700, Ali Çehreli via Digitalmars-d-learn wrote: > On 4/17/22 08:13, HuskyNator wrote: [...] > > - 2: Why does adding a constructor to a struct disable the use of > > the static initialization syntax? > > I am not sure how to answer this question because I am about to say > don't use the static initialization syntax. :/ To me, idiomatic way of > constructing D objects is > > auto m = Mat!2([1,2]); > > The reason why one cannot define a default constructor for a D struct > is because every type in D must have a statically known .init value. A > user-defined default constructor could not be known at compile time. IME, when the lack of default ctors in D starts bothering me, that's usually around the time the struct really ought to be rewritten as a class (which *does* support default ctors). Structs in D ought to be treated like "glorified ints", as Andrei puts it. If you need complex ctors and complex methods, that's a sign you should be using a class instead. [...] > Really, compared to C++, the amount of constructor, destructor, copy > constructor, etc. that I do *not* write in D is very liberating to me. > It feels like I just write what is needed and it mostly just works. [...] One thing about idiomatic D code is that it embraces the "create the object first, then kick it into shape" philosophy, vs. the "meticulously manage the initialization of every last bit in the ctor so that the object comes out of the ctor call a perfect product ready to ship" philosophy. The latter requires a lot of boilerplate and micromanagement of object state; the former, when done well, leads to streamlined code that gets its job done with a minimum of fuss. T -- Never criticize a man until you've walked a mile in his shoes. Then when you do criticize him, you'll be a mile away and he won't have his shoes.
Re: Static struct initialization syntax behavior & it being disabled upon adding a constructor
On 4/17/22 08:13, HuskyNator wrote:
> - 1: Why does `m` initialization behave as if `m[0][]=1` and `m[1][]=2`
> were used? (Shouldn't this code result in an error instead?)
That's pretty weird. I think it boils down to scalar assignment to an
array being valid:
void main() {
int[3] arr;
arr = 42;// Feature? (Yes.)
import std.algorithm : all;
assert(arr[].all!(e => e == 42));
}
So, in the end, each element of your argument array gets assigned to
each element of member array. Makes sense (to me :) )...
I think the initialization of 'n' is more straightforward.
> - 2: Why does adding a constructor to a struct disable the use of the
> static initialization syntax?
I am not sure how to answer this question because I am about to say
don't use the static initialization syntax. :/ To me, idiomatic way of
constructing D objects is
auto m = Mat!2([1,2]);
The reason why one cannot define a default constructor for a D struct is
because every type in D must have a statically known .init value. A
user-defined default constructor could not be known at compile time.
> it now requires me to
> write additional constructors, as soon as I want to add 1.
I don't see it as a big problem in practice. As soon as I need to add a
constructor, the default behavior of setting members to arguments seems
out of place. Either the one constructor is sufficient or write at most
another one at most.
> the commonly suggested workarounds (using `opCall`) seems
> rather inelegant to me.
Agreed. And static opCall() is not usable in all cases as it somehow
conflicts in some cases. (Don't remember now.)
> Why is this possible in C++ in contrast?
C++ does not insist that all types have a statically known .init value.
If I'm not mistaken, the part about disabling certain constructors, move
or otherwise, is commonly accepted in C++ as well.
Really, compared to C++, the amount of constructor, destructor, copy
constructor, etc. that I do *not* write in D is very liberating to me.
It feels like I just write what is needed and it mostly just works.
Ali
Static struct initialization syntax behavior & it being disabled upon adding a constructor
This is a twofold question, along the example code below:
- 1: Why does `m` initialization behave as if `m[0][]=1` and
`m[1][]=2` were used? (Shouldn't this code result in an error
instead?)
- 2: Why does adding a constructor to a struct disable the use of
the static initialization syntax? I only see it mentioned in the
documentation indirectly (there are notes in the example code
specifying as such, but the text itself does not seem to define
their removal). I also don't see how this behavior is beneficial,
as it now requires me to write additional constructors, as soon
as I want to add 1.
```d
struct Mat(int n){
int[n][n] mat;
void write(){
writeln(mat);
}
// Will cause the m & n initialisations to yield errors.
// this(int i){
// mat[0][0] = i;
// }
}
void main() {
Mat!2 m = {[1,2]}; // Prints [[1, 1], [2, 2]]
Mat!2 n = {[[1,2],[3,4]]}; // Prints [[1, 2], [3, 4]]
m.write();
n.write();
}
```
PS:
Are there any plans to change the behaviour of empty struct
constructors? (eg: `this(){}`) It surprised me greatly coming
into D, and one of the commonly suggested workarounds (using
`opCall`) seems rather inelegant to me. Why is this possible in
C++ in contrast?
Re: Struct Initialization syntax
On Tuesday, 24 July 2018 at 16:35:32 UTC, H. S. Teoh wrote:
On Tue, Jul 24, 2018 at 01:13:16PM +, 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?
Re: Struct Initialization syntax
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 +, 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 };
?
Re: Struct Initialization syntax
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.
Re: Struct Initialization syntax
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() {...}
}
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(color>) {}
// struct style
struct DrawRect
{
int x, y, width, height;
string color;
}
void drawRect(DrawRect rect) {}
Re: Struct Initialization syntax
On Tue, Jul 24, 2018 at 01:13:16PM +, 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
--
Старый друг лучше новых двух.
Re: Struct Initialization syntax
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.
Re: Struct Initialization syntax
On Tuesday, 24 July 2018 at 10:48:40 UTC, Dukc wrote: On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote: What's your take on this? Option 2 won't necessarily cause problems with named funcion arguments: The names of the constructor arguments and members are different anyway, at least usually, letting the compiler to infer the intended call by them. But there might be some corner cases where this would not apply. Do you see any? 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.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote: What's your take on this? Option 2 won't necessarily cause problems with named funcion arguments: The names of the constructor arguments and members are different anyway, at least usually, letting the compiler to infer the intended call by them. But there might be some corner cases where this would not apply. Do you see any?
Re: Struct Initialization syntax
On 24/07/2018 7:23 PM, Daniel N wrote: On Tuesday, 24 July 2018 at 03:59:53 UTC, rikki cattermole wrote: On 24/07/2018 6:43 AM, kinke wrote: On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote: Can we just consider that named struct init syntax *is* a generated named constructor? If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency. +1. And hoping for the latter, seamless consistency. Based upon my DIP that is in the queue for named arguments, it would be trivial for this DIP to make it so a named parameter constructor can override the default behavior and I think that this is the best way forward. Yes, it makes sense to review the "named arguments" DIP before this one, any link? Mine: https://github.com/dlang/DIPs/pull/126 Yshui's: https://github.com/dlang/DIPs/pull/123 Mine is a lot heavier-weight, and applies to templates parameters as well as functions. Where as Yshui's is very lightweight compared and only applies to functions. Yshui's will occur first I think, but really we should review them together to decide what sort of approach is best.
Re: Struct Initialization syntax
On Tuesday, 24 July 2018 at 03:59:53 UTC, rikki cattermole wrote: On 24/07/2018 6:43 AM, kinke wrote: On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote: Can we just consider that named struct init syntax *is* a generated named constructor? If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency. +1. And hoping for the latter, seamless consistency. Based upon my DIP that is in the queue for named arguments, it would be trivial for this DIP to make it so a named parameter constructor can override the default behavior and I think that this is the best way forward. Yes, it makes sense to review the "named arguments" DIP before this one, any link?
Re: Struct Initialization syntax
On 24/07/2018 6:43 AM, kinke wrote: On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote: Can we just consider that named struct init syntax *is* a generated named constructor? If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency. +1. And hoping for the latter, seamless consistency. Based upon my DIP that is in the queue for named arguments, it would be trivial for this DIP to make it so a named parameter constructor can override the default behavior and I think that this is the best way forward.
Re: Struct Initialization syntax
On 24/07/2018 7:11 AM, Jacob Carlborg wrote:
On 2018-07-23 18:26, Seb 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
}
---
So the struct-initialization DIP has been stalled for too long and I
think it's time we finally get this story done.
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?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
Talking about future potential features, Option 1 could be in conflict
with a tuple with named elements. Option 2 could be in conflict with
named parameters, true, but named parameters could also have a different
syntax, i.e. foo(a = 3, b = 4), this is what Scala is using.
We ugh can't use that syntax because of ambiguity to AssignExpression.
Re: Struct Initialization syntax
On 2018-07-23 18:26, Seb 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
}
---
So the struct-initialization DIP has been stalled for too long and I
think it's time we finally get this story done.
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?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
Talking about future potential features, Option 1 could be in conflict
with a tuple with named elements. Option 2 could be in conflict with
named parameters, true, but named parameters could also have a different
syntax, i.e. foo(a = 3, b = 4), this is what Scala is using.
--
/Jacob Carlborg
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote: Can we just consider that named struct init syntax *is* a generated named constructor? If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency. +1. And hoping for the latter, seamless consistency.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 18:02:04 UTC, Andre Pany wrote: I also prefer option 3. From a readability point of view it is the most pleasant one (my personal opinion). I also like it due to the already existing struct initialization syntax I am using a lot. +1. JohnB.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:57:20 UTC, H. S. Teoh wrote:
On Mon, Jul 23, 2018 at 04:26:42PM +, 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
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
+1.
I personally prefer option 2, but this might be in conflict to
named arguments which we hopefully see in the near future too.
Yeah.
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?
[...]
I don't like option 1 because it resembles anonymous function
syntax and AA initialization syntax, but is actually neither.
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.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb 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
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
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?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
I also prefer option 3. From a readability point of view it is
the most pleasant one (my personal opinion). I also like it due
to the already existing struct initialization syntax I am using a
lot.
Kind regards
Andre
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 17:46:12 UTC, H. S. Teoh wrote: Yes, this is what I was trying to get at. Thanks! If such integration was possible then that sounds like it would be a good solution.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 17:46:12 UTC, H. S. Teoh wrote: I worded myself poorly. What I meant was that if a ctor parameter has the same name as a field, then it's obviously meant to initialize that field, so there isn't really a conflict, you're just passing the argument to the ctor instead of setting it directly to the struct. It would be a horrendously bad idea to have a ctor parameter that has the same name as a field, but is used to initialize a different field. [...] If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency. [...] Yes, this is what I was trying to get at. Thanks! T Hehe oops, indeed you were :p Seems I did not parse properly. Apologies! Cheers, - Ali
Re: Struct Initialization syntax
On Mon, Jul 23, 2018 at 05:32:23PM +, aliak via Digitalmars-d wrote:
> On Monday, 23 July 2018 at 16:57:20 UTC, H. S. Teoh wrote:
>
> > It's true that there's potential conflict with named arguments, but
> > IMO it's a mighty bad idea to name ctor parameters in a way that
> > conflicts with the struct fields.
>
> After using Swift for a while, I've found this to be the exact
> opposite. It is on the contrary very common to name parameters as you
> would your members because they are very commonly the most intuitive
> names.
[...]
I worded myself poorly. What I meant was that if a ctor parameter has
the same name as a field, then it's obviously meant to initialize that
field, so there isn't really a conflict, you're just passing the
argument to the ctor instead of setting it directly to the struct. It
would be a horrendously bad idea to have a ctor parameter that has the
same name as a field, but is used to initialize a different field.
OTOH, if you have a ctor, then one would assume that you're
intentionally overriding direct initialization of fields, so you
wouldn't want people to be using named initialization of fields anyway,
they should be using the ctor instead. So any conflicts in this area
wouldn't really be relevant.
> struct Point {
> int x, int y;
> this(x: int, y: int) {}
> }
>
> auto p = Point(x: 3, y: 4); // what else would you name them?
>
> Can we just consider that named struct init syntax *is* a generated
> named constructor?
>
> If named arguments choose a different syntax then you have no
> conflict. If they go with the same (i.e. option 2) then you have
> seamless consistency.
[...]
Yes, this is what I was trying to get at. Thanks!
T
--
Don't modify spaghetti code unless you can eat the consequences.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:57:20 UTC, H. S. Teoh wrote:
It's true that there's potential conflict with named arguments,
but IMO it's a mighty bad idea to name ctor parameters in a way
that conflicts with the struct fields.
After using Swift for a while, I've found this to be the exact
opposite. It is on the contrary very common to name parameters as
you would your members because they are very commonly the most
intuitive names.
struct Point {
int x, int y;
this(x: int, y: int) {}
}
auto p = Point(x: 3, y: 4); // what else would you name them?
Can we just consider that named struct init syntax *is* a
generated named constructor?
If named arguments choose a different syntax then you have no
conflict. If they go with the same (i.e. option 2) then you have
seamless consistency.
Cheers,
- Ali
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 17:10:08 UTC, Cym13 wrote:
PS: Now that I think about it, would something like S{c:3}("a")
be allowed to say “Call the constructor with the string "a" as
argument on the struct of type S initialized with c=3”? I may
have missed it but I don't think that's addressed by the DIP.
I took that last point to GH, no need to discuss it here.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb 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
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
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?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
I'm in favour of 3.
Option 2 looks nice but I'm against it because of possible named
arguments. Even though they're not part of the language yet and
may never be we already have too many clunky things not to avoid
a conflict when we can.
Option 1 is clean but a bit strange, I don't like the idea of
doubling the enclosing symbols, in that situation you'd expect
S() and {} to have separate effects, not to combine into a
special effect. It also looks like a constructor while it's not,
which isn't a nice conflation to make. I wouldn't be very
dismayed by it though.
Still, that's why I prefer option 3 which is very similar to
classical struct initialization and has clearly only one effect.
PS: Now that I think about it, would something like S{c:3}("a")
be allowed to say “Call the constructor with the string "a" as
argument on the struct of type S initialized with c=3”? I may
have missed it but I don't think that's addressed by the DIP.
Re: Struct Initialization syntax
On Mon, Jul 23, 2018 at 04:26:42PM +, 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
> }
> ---
>
> So the struct-initialization DIP has been stalled for too long and I
> think it's time we finally get this story done.
+1.
> I personally prefer option 2, but this might be in conflict to named
> arguments which we hopefully see in the near future too.
Yeah.
> 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?
[...]
I don't like option 1 because it resembles anonymous function syntax and
AA initialization syntax, but is actually neither.
I'm on the fence about option 2 and option 3.
I actually prefer option 3 as being overtly special initialization
syntax that doesn't try to masquerade as something else.
But OTOH, option 2 has a lot going for it, given that today, S(x, y, z)
is the syntax for initializing struct fields in order, so one would
expect that S(p: x, q: y, r: z) ought to be a natural extension of the
syntax for specifying fields out-of-order (or with some fields omitted).
It's true that there's potential conflict with named arguments, but IMO
it's a mighty bad idea to name ctor parameters in a way that conflicts
with the struct fields. Either your struct has a member named x, your
ctor uses parameter names that are different from x (thus avoiding the
confusion), or if your ctor also takes a parameter named x, in which
case one would expect that it would initialize the member x, as opposed
to a different member y. To have a ctor take a parameter named x but
using it to initialize member y instead of member x, seems to be such a
horrible idea that it should not be a big deal for struct initialization
syntax to "conflict" with it.
T
--
If you want to solve a problem, you need to address its root cause, not just
its symptoms. Otherwise it's like treating cancer with Tylenol...
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote: 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? Although a bit more verbose that seems like a good choice. If you could save the “initialization list” in an enum that choice also seems to generalize better. Not conflicting with named arguments is important for me, as named arguments would be very nice to have for hardware description kind of stuff.
Struct Initialization syntax
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
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
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?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
Re: Struct initialization syntax
On Thursday, 18 January 2018 at 03:50:15 UTC, arturg wrote: On Wednesday, 17 January 2018 at 17:37:07 UTC, H. S. Teoh wrote: On Wed, Jan 17, 2018 at 05:31:03PM +, Azi Hassan via Digitalmars-d-learn wrote: The D tour for structs uses a syntax similar to that of C++ in order to initialize a Person struct : Person p(30, 180). Is this syntax supported in D ? Running that part of the code neither works on the playground nor on my machine (dmd v2.076.0). You're probably looking for this syntax: auto p = Person(30, 180); T looks like a bug in the 3rd example. That's what I was wondering about, thanks.
Re: Struct initialization syntax
On Thu, Jan 18, 2018 at 03:50:15AM +, arturg via Digitalmars-d-learn wrote: > On Wednesday, 17 January 2018 at 17:37:07 UTC, H. S. Teoh wrote: > > On Wed, Jan 17, 2018 at 05:31:03PM +, Azi Hassan via > > Digitalmars-d-learn wrote: > > > The D tour for structs uses a syntax similar to that of C++ in order > > > to initialize a Person struct : Person p(30, 180). Is this syntax > > > supported in D ? Running that part of the code neither works on the > > > playground nor on my machine (dmd v2.076.0). > > > > You're probably looking for this syntax: > > > > auto p = Person(30, 180); > > > > > > T > > looks like a bug in the 3rd example. Indeed. Here's a fix: https://github.com/dlang-tour/english/pull/230 T -- Not all rumours are as misleading as this one.
Re: Struct initialization syntax
On Wednesday, 17 January 2018 at 17:37:07 UTC, H. S. Teoh wrote: On Wed, Jan 17, 2018 at 05:31:03PM +, Azi Hassan via Digitalmars-d-learn wrote: The D tour for structs uses a syntax similar to that of C++ in order to initialize a Person struct : Person p(30, 180). Is this syntax supported in D ? Running that part of the code neither works on the playground nor on my machine (dmd v2.076.0). You're probably looking for this syntax: auto p = Person(30, 180); T looks like a bug in the 3rd example.
Re: Struct initialization syntax
On Wed, Jan 17, 2018 at 05:31:03PM +, Azi Hassan via Digitalmars-d-learn wrote: > The D tour for structs uses a syntax similar to that of C++ in order > to initialize a Person struct : Person p(30, 180). Is this syntax > supported in D ? Running that part of the code neither works on the > playground nor on my machine (dmd v2.076.0). You're probably looking for this syntax: auto p = Person(30, 180); T -- Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.
Struct initialization syntax
The D tour for structs uses a syntax similar to that of C++ in order to initialize a Person struct : Person p(30, 180). Is this syntax supported in D ? Running that part of the code neither works on the playground nor on my machine (dmd v2.076.0).
