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.
