Is it time for D 3.0?

[Joseph Rushton Wakeling]

On Wednesday, 1 April 2020 at 13:26:20 UTC, Steven Schveighoffer 
wrote:
> I think what John is saying is that it's nearly impossible. 
> With introspection, literally EVERYTHING becomes part of the 
> API, including all names of parameters to functions.
>
> It doesn't mean that the API is defined as that, however. But 
> it does mean that code that uses funky techniques might break 
> when something is changed that is not expected to cause a 
> problem.
>
> However, I think we can define what the API does include, and 
> basically warn people "don't depend on this". I just don't 
> think we do that anywhere.

Ah, OK.  That does make sense.  And yes, I agree that strong 
clarity on what can robustly be introspected in upstream code, 
and what not, would be a very good thing.  Is this in principle 
something that we could automate warnings about?

(I say warnings because I don't imagine banning such 
introspection would be helpful.  After all one could probably do 
these things internally in a codebase -- on entities you control 
and hence where you can prevent breakage -- and get benefit out 
of them.  So there would have to be some way to indicate intent 
to do the risky thing.)

> Your point about deprecations is a very good one. I think we 
> should switch to that (only one deprecation removal release per 
> year). We could probably engineer a versioning system that 
> makes this detectable based on the version number.

Well, for example, if we made the breaking changes happen in the 
first release of the year, we could version D in annual epochs.  
D 2020 anyone? :-)

[Bad pun, but: did anyone write up a D 2020 vision? ;-)]

On the broader original topic of your first post -- I do agree 
that it's really starting to feel like it's time for another 
major revision to the language, as that will allow some very 
desirable features to be done much more solidly (or be done at 
all).  As someone who still wants to get a lot of production use 
out of D in the next years, I'd MUCH rather have a breaking 
change that gets us to even more awesome places, than stability 
and less powerful features.

I'm not sure I would agree with all your listed examples -- e.g. 
I'm reluctant to endorse pure by default as I think that would 
clash too much with the ability to just script easily -- but that 
sort of stuff is for future discussion anyway.  The core idea of 
wanting to make another major language revision seems sound.