Future of D 2.x as stable/bug fix, and what's next for D 3.x

[H. S. Teoh]

On Mon, Aug 31, 2020 at 07:11:40PM +0000, IGotD- via Digitalmars-d wrote:
> On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:
> > 
> > Do you really think these same people are going to come to a clear
> > consensus about stability vs. innovation?
> 
> That's the impression I get from reading this forum. DIPs that are
> small tweaks that breaks nothing or very little often get positive
> feedback. DIPs that makes big breaking changes or tries fork in a new
> piece of technology often has more controversy around it. Now, you
> would say that this is completely natural but still I haven't seen
> that big enthusiasm regarding the bigger changes. That's my
> observation when it comes to D. When it comes to other languages, I
> don't know but they are often governed in some other fashion like C++.

>From my POV, the controversies usually involve 3 main factors:

- The desire not to break existing code: this used to be a smaller
  problem, but these days it seems we're treading on eggshells whenever
  something might potentially break code;

- The desire for major new features with breaking changes, to rid the
  language of unwanted baggage and add desirable features that we can't
  currently add because it conflicts with the way things are currently
  done.

- The desire to balance the previous two by making smaller changes --
  but the change gets seen as anemic and not going far enough to be
  actually useful and justify the cost.


I've mentioned before (though I'm not 100% sure how practical it would
be with D) that one way to move forward is to introduce a language
versioning mechanism to D, such that each module declares which language
version it was written in. The compiler would internally have multiple
versioned components that represent selected "frozen" states of the
language, which would be selected by this version directive so that it
retains the old semantics of the language. Ideally, this would allow us
to retain complete backward compatibility (at least up to the point this
versioning system was introduced) while allowing newer language versions
to break things as necessary to implement new features. Since the
versioning will apply by module, one can incrementally upgrade code to
newer language versions without being forced to fix everything all at
once upon installing a newer compiler.

Of course, there's bound to be cases where an older language version is
fundamentally incompatible with a newer version; in such cases perhaps
it can be a compile error if a newer module interacts with an older
module in a way that falls under such incompatibilities. The idea being
to catch this at compile-time instead of breaking stuff at runtime.

IOW, it's what Andrei has been repeating about adding rather than
changing. Add new versions of the language in the same compiler, instead
of changing the meaning of the current version of the language.


T

-- 
Don't get stuck in a closet---wear yourself out.