Is it time for D 3.0?

[Mathias LANG]

On Thursday, 2 April 2020 at 22:51:18 UTC, Joseph Rushton 
Wakeling wrote:
> 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?

That's actually a topic I was very interested in when I was 
working at Sociomantic. We had a pretty good versioning thing 
going on with libraries, but it was never formally defined what 
was an acceptable change. As mentioned, the ability to do `static 
if (!__traits(compiles, ...))` (notice the negation: checking 
that something does not compile) means that, except for 
introducing a new module (but that's due to a compiler limitation 
that we'd eventually fix), everything can be considered a 
breaking change, if you're a purist.

I've always been very fond of 
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B as it describes the techniques one can use to ensure binary compatibility in C++ program, and wish we had the same in D.

> (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.)

We don't do warnings. We have some, but they are an historical 
bagage. I know Walter oppose to it, it was brought up multiple 
times.

>> 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? :-)

I still think the deprecation scheme should take a few more 
things into account, e.g. how long has the replacement feature 
been available for ? What bugs are triggered by the feature that 
is to be removed ? How much is it used ?
For example, the body deprecation: Most of the gains come from 
making `body` a context-dependent keyword, and allowing `do`. 
Removing `body` as a keyword doesn't actually help the user. It 
doesn't bring them value. Additionally, TONS of code out there 
use `body`. Using `body` does not cause bugs at all. And the 
replacement was introduced only shortly before deprecation.
For this reason, we could keep it in the language for a very long 
time (5 years at least), and just undocument  it /  replace 
usages as we can.

On the other hands, D1 operator overloads: The replacement (D2) 
have been around for over a  decade. They have different 
priorities, so they don't mix well with their replacement, 
leading to subtle bugs (which was actually what triggered their 
deprecation). However there is A LOT of code out there that still 
uses them, so that's why I would want us to go with at least a 2 
year deprecation period.

> 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.

That's a good point. There's no escape hatch for `pure`. How do I 
call `writeln` from main ?