Dicebot on leaving D: It is anarchy driven development in all its glory.

[Chris]

On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
>
> You want to remove autodecoding (so do I) and that will break 
> just about every D program in existence. For everyone else, 
> it's something else that's just as important to them.

I wanted to get rid of autodecode and I even offered to test it 
on my string heavy code to see what breaks (and maybe write 
guidelines for the transition), but somehow the whole idea of 
getting rid of autodecode was silently abandoned. What more could 
I do?

I am fully aware of the fact that it's always something else to 
someone else. But you can have a list of common sense priorities. 
For example, fast and efficient string handling should be up 
there, because in times of data mining and machine learning (cf. 
translation tools) string handling is _very_ important.

My suggestion is

- breakage only where it is absolutely necessary

- new features as opt in but not as breaking features

- new versions of dmd should be more tolerant of older code. Say, 
let's introduce a _guaranteed_ backwards compatibility of at 
least N versions. In this way one could work with the latest 
version (and benefit from new features, bug fixes, optimizations) 
and bit by bit upgrade old code as you go along.

- maybe introduce a feature freeze for a while and have a poll 
about which features are really being used on a day to day basis. 
In this way you can spend time on fixing stuff that is really 
needed instead of wasting time on features that are not really 
used that often (as seems to be the case with @safe)

- stick to a list of clear goals instead of taking on board 
random requests, interesting as they may be. In other words: more 
focused work, harden your heart a little bit ;)


> For example, Shachar wants partially constructed objects to be 
> partially destructed, a quite reasonable request. Ok, but 
> consider the breakage:
>
>   struct S {
>     ~this() {}
>   }
>
>   class C {
>     S s;
>
>     this() nothrow {}
>   }
>
> I.e. a nothrow constructor now must call a throwing destructor. 
> This is not some made up example, it breaks existing code:
>
>   https://github.com/dlang/dmd/pull/6816
>
> If I fix the bug, I break existing code, and apparently a 
> substantial amount of existing code. What's your advice on how 
> to proceed with this?

I have no opinion on this. But it's indicative of the way D is 
being developed atm. A half baked feature (partially constructed 
objects with no partial destructor) that if you fix it, breaks 
existing code. But what for was it introduced at all and why 
wasn't it thought through properly right from the start?

See if I donate (a humble amount of) money to the D foundation I 
don't want to see it used on experimental container library 
optimizations. I want it to be spent on D being turned into a 
sound and stable language with certain guarantees.