Is it time for D 3.0?

[Steven Schveighoffer]

On 4/1/20 8:43 AM, Joseph Rushton Wakeling wrote:
> On Wednesday, 1 April 2020 at 09:40:34 UTC, John Colvin wrote:
>> So many things in D are breaking changes. Because of introspection and 
>> __traits(compiler,...) etc. almost any bug fix can break someone's 
>> code. Even introducing an entirely disjoint overload for a function 
>> can be a breaking change.
>>
>> It would be an interesting but daunting (impractical?) task to 
>> characterise what is considered "API" and what is "implementation 
>> detail" in phobos.
> 
> Has there ever been any kind of systematic effort to record and 
> categorize those sorts of introspection-based breakages?  I'm wondering 
> if there are any regularities to what breaks that would help us avoid 
> them more rigorously.

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.

With a more robust versioning system, we could also provide a "breaking" 
branch which is expected to change, and a "non-breaking" branch which is 
expected never to break anything. Right now we have a grey area with both.

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.

-Steve