Would love to override default ctor of struct

[Jonathan M Davis]

On Monday, January 21, 2019 6:23:21 PM MST aliak via Digitalmars-d wrote:
> On Saturday, 19 January 2019 at 11:13:22 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, January 19, 2019 3:05:22 AM MST Dru via
> >
> > Digitalmars-d wrote:
> >> What is the idea behind why we can't define default ctor for
> >> structs?
> >>
> >> In current situation I need to "@disable this()"
> >> then define a constructor with dummy arguments  (because my
> >> constructor does not need arguments)
> >>
> >> It is a big pain on syntax
> >
> > Structs in D don't actually have default constructors. Rather,
> > they have a default value that they're initialized to - namely
> > T.init (where T is the type name). In fact, all types in D have
> > a default value so that they're guaranteed to not be garbage if
> > you forget to initialize them with a specific value. This gets
> > taken advantage of in a number of places. One obvious one is
> > arrays. The init value can simply be blitted into all of the
> > elements of the array. A number of features in D are built
> > around that and really don't work without it.
>
> I've always wondered why T.init can't be it's own thing and
> separate from this(). So if someone defined a this() then D just
> treats it like a custom non-default constructor? Not possible?

If D allowed struct's to have a constructor without any parameters, it would
not be and could not be a default constructor because of how init works. It
would only be a constructor that was called when used explicitly. As such,
it wouldn't really add much over just using a factory function, and it would
run a serious risk of confusing people, because newcomers would expect
this() to be a default constructor when it wasn't. It also would be bad for
porting code to D from languages like C++, because without extra work from
the programmer, the code would assume that this() was a default constructor
when it wasn't, making it easy to end up with subtle bugs. By outright
making this() illegal, D forces the programmer to deal with the situation
rather than allowing silent bugs. If it hadn't, I can guarantee that there
would have been tons of confusion and complaints over how this() wasn't
working correctly, because everyone coming to D would expect it to be a
default constructor and then be very confused when it wasn't being called in
code like

Foo foo;

or

auto arr = new Foo[](42);

The only downside that I can think of at the moment for using a factory
function over having this() as a non-default constructor is that when
constructing immutable objects, the constructor usually has to do it (though
in some situations, casts could be used - that depends primarily on whether
the data is guaranteed to be unique). So, such a factory function would
require a special constructor with dummy arguments or something similar in
order to construct immutable objects. But aside from that, a factory
function is just as good as a constructor, and it doesn't carry with it the
confusion of whether this() is a default constructor or not.

- Jonathan M Davis