D is dead

[Jonathan M Davis]

On Saturday, August 25, 2018 2:16:16 PM MDT Walter Bright via Digitalmars-d 
wrote:
> On 8/25/2018 7:37 AM, Jonathan M Davis wrote:
> > In general, any place where D was
> > designed around the idea that something would _always_ be there (e.g.
> > init values and default initialization) but we've then later added the
> > ability to get around it (e.g. void initialization or @disable) has
> > tended to not play well with everything else and has caused some fun
> > problems.
>
> It's why that stuff isn't allowed in @safe code, and hence one should
> realize one is taking responsibility from the compiler for ensuring the
> correctness. D expects someone writing @system code to have a much
> greater awareness of how the language and the machine works.
>
> If you remove the blade guards from the table saw, more things can be done
> with it, but you'll need to take much greater care using it.

Definitely, but some of the features don't play well together even with
@system - e.g. if you have a struct with an invariant, you can't use void
initialization, because the invariant will be checked when you assign the
struct an actual value later. I was forced to remove the invariant that
SysTime had years ago, because of issues related to that, and I've basically
given up on using invariants in structs as a result. If I'm in full control
of all of the code, it's not a problem, but as soon as I'm providing library
code to someone eles, struct invariants become land mines.

And just in general, it becomes pretty problematic to try to skip or disable
something that the lanugage was built around (e.g. default initialization) -
though fortunately, it usually interacts better than invariants tend to do
when you do something like void initialization.

- Jonathan M Davis