Would love to override default ctor of struct

[Jonathan M Davis]

On Thursday, January 31, 2019 4:42:35 AM MST Nick Treleaven via Digitalmars-
d wrote:
> On Tuesday, 22 January 2019 at 02:18:37 UTC, Jonathan M Davis
>
> wrote:
> > 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.
>
> D could solve this by only allowing a nullary constructor when
> there's `@disable this();`. The fact that `@disable this()`
> exists undermines the reason for a blanket ban on `this(){...}`,
> and I expect it's this way just because disable this was added
> later. This is worth having and would support Mutex, HourGlass,
> etc.
>
> Besides runtime immutable initialization not working in a free
> function 'constructor' as you mentioned, not allowing a nullary
> constructor breaks the variadic constructor pattern in generic
> code when no arguments are passed.

The main problem with allowing a constructor with no parameters when you
@disable this(); is that it wouldn't act like a default constructor and
really couldn't act like one in general, because too much is designed around
using init. To make it work, you'd have to start making stuff work one way
with init normally and another way when @disable this() was present, which
would be confusing and likely error-prone.

And yes, the issues with @disable this(); stem from the fact that it was
shoehorned into the language later. D was very much designed around the idea
that all types are always default initialized, and any attempt to work
around that starts causing problems. @disable this(); is rather similar to
= void; in that regard. There are cases where it makes sense to use them,
but you need to know what you're doing, and their use should be quite rare.
They're basically backdoors to force the language to do something that it's
really not designed to do.

Also, it's perfectly possible to use a factory function to create immutable
objects. Worst case, you have to cast to immutable in the factory function,
but it works just fine. AFAIK, aside from stuff that requires that the type
be default-initialized, the only thing that you can't really do with
@disable this(); is to completely guarantee that all objects are constructed
via the factory method, because the init value for the type still exists and
can still be used. It just isn't used for default initialization. So, having
a type with @disable this(); that does not take the init value into account
can cause bugs. But all of the other stuff with regards to immutable and the
like can still be done. It just can't necessarily be done in an @safe
manner.

- Jonathan M Davis