Is it time for D 3.0?

[Steven Schveighoffer]

On 4/3/20 1:00 AM, Mathias LANG wrote:
> 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?

I don't think warnings are possible. But I'd say we can at least have a 
list of changes that the D library considers to be "non-breaking 
changes", even if they will break introspective code. What that list is, 
I have not thought of. But it should be something discussed, especially 
if we are to have a more formal versioning system.

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

Yeah, that just leads to breaking changes being OK, since you can't 
avoid breaking changes.

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

D uses source compatibility almost exclusively, because of the vast 
metaprogramming capabilities -- you have to recompile because any slight 
change in a function or type is going to require a rebuild.

Only a library that is focused on binary compatibility could specify 
such a thing. Druntime and Phobos can't be in that boat.

>>> 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 think deprecations should have a time requirement (at least X 
years/months), but also only be done periodically.

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

Yes, it's simply the maximum of X time and the next "breaking" release.

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

I think you mean removing body as a contextual keyword doesn't help the 
user because he can use `body` today as a normal variable name, right?

I agree with that, it's not critical to remove the "alternate" keyword 
for `do` here.

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

For sure. opInc or opAdd is a lot easier and quicker to write than 
opBinary(string op: "+"). So there is going to be a lot of code that 
just does the former.

We still have yet to provide a mixin that provides the forwarding system 
(i.e. if you have opAdd or opInc, it will define appropriate 
forwarding). Something like this I think should be a good library or 
object.d inclusion.

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

That was just a list of wishes, not necessarily what I want.

All the "by default" wishes stem from the fact that a) much non-template 
code is written that is already pure/safe/nothrow, but unless you tag 
it, they are not usable from that realm, and b) tagging everything in 
all the ways they are supposed to be tagged is tedious and verbose.

Honestly, I'd say a mechanism to affect the defaults:

pragma(default_attributes, pure, @safe, nothrow);

or something like that would go a long way. And you would need opposites 
for all to make that work (i.e. throw, impure, @system).

Then you can alter the defaults, and there truly is an escape hatch to 
go back to the way it was. I too would list pure as one that is too 
difficult to workaround to be a default default, especially since the 
standard hello world would fail to compile!

-Steve