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

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.

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"..

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.

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/thsjtreegdwcgbazhczd@forum.dlang.org

The reasoning still feels flimsy and stubborn.

On Mon, Apr 18, 2022 at 08:22:26AM +0000, 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.