On Tuesday, 31 March 2020 at 23:25:31 UTC, Joseph Rushton Wakeling wrote:
> On Tuesday, 31 March 2020 at 17:52:39 UTC, Mathias LANG wrote:
>> Why do you think it would ? At the moment we have a sliding window for deprecation. We'd just change that to have a specific time for removal. I don't see how that would make every release a breaking change ?
>
> Yup, assuming the current 3-month release cadence continues it would make sense to make all breaking changes in only one of those 4 quarterly releases.  A Christmas present to the community? O:-)

That would be a step... Sideways ?

Currently we follow this: https://github.com/dlang/DIPs/blob/5afe088809bed47e45e14c9a90d7e78910ac4054/DIPs/accepted/DIP1013.md
Personally, the main disruption I had over the last 2 years was the concurrent GC (a new feature) being enabled by default. There was hardly any breaking change.

With the current 10-release deprecation period and 3-months between release, this means a deprecation is up for 30 months, or 2 1/2 years before being removed. I don't think we should shorten it any further, it already proved problematic on some occasions (e.g. body => do).

On Wednesday, 1 April 2020 at 05:30:41 UTC, Mathias LANG wrote:
> On Tuesday, 31 March 2020 at 23:25:31 UTC, Joseph Rushton Wakeling wrote:
>> On Tuesday, 31 March 2020 at 17:52:39 UTC, Mathias LANG wrote:
>>> Why do you think it would ? At the moment we have a sliding window for deprecation. We'd just change that to have a specific time for removal. I don't see how that would make every release a breaking change ?
>>
>> Yup, assuming the current 3-month release cadence continues it would make sense to make all breaking changes in only one of those 4 quarterly releases.  A Christmas present to the community? O:-)
>
> That would be a step... Sideways ?
>
> Currently we follow this: https://github.com/dlang/DIPs/blob/5afe088809bed47e45e14c9a90d7e78910ac4054/DIPs/accepted/DIP1013.md
> Personally, the main disruption I had over the last 2 years was the concurrent GC (a new feature) being enabled by default. There was hardly any breaking change.
>
> With the current 10-release deprecation period and 3-months between release, this means a deprecation is up for 30 months, or 2 1/2 years before being removed. I don't think we should shorten it any further, it already proved problematic on some occasions (e.g. body => do).

Small correction: we have a major release every two months - see: https://dlang.org/changelog/release-schedule.html

You can see the history of releases here: https://dlang.org/changelog/index.html

On Wednesday, 1 April 2020 at 06:58:47 UTC, Petar Kirov [ZombineDev] wrote:
> On Wednesday, 1 April 2020 at 05:30:41 UTC, Mathias LANG wrote:
>> [...]
>
> Small correction: we have a major release every two months - see: https://dlang.org/changelog/release-schedule.html
>
> You can see the history of releases here: https://dlang.org/changelog/index.html

s/major release/minor release/

On Friday, 27 March 2020 at 17:32:44 UTC, H. S. Teoh wrote:
> On Fri, Mar 27, 2020 at 11:56:40AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
>> There have been a lot of this pattern happening:
>> 
>> 1. We need to add feature X, to fix problem Y.
>> 2. This will break ALL CODE IN EXISTENCE
>> 3. OK, cancel the fix, we'll just live with it.
>> 
>> Having a new branch of the compiler will provide a way to keep D2 development alive while giving a playground to add new mechanisms, fix long-existing design issues, and provide an opt-in for code breakage.
>
> What about supporting multiple versions of the language simultaneously, using some kind of version directive at the top of each file?  It will mean more work to develop and maintain the compiler, but the benefit is that *no* code will break, and users can migrate old code incrementally and at their leisure by bumping the version directive on a file and fixing any subsequent errors.
>
> As Andrei said once, one solution to the problem of not breaking old code while improving new code is additive enhancements rather than replacing old things outright.  If there's a breaking language change, maybe there's a way to keep the old behaviour for old code while changing it for new code. Versioned source files is one way to do this, albeit at the cost of greater complexity in the compiler.
>
>
>> Some issues I can think of:
>> 
>> 1. The safe by default debate
>> 2. pure by default
>> 3. nothrow by default
>> 4. String interpolation DIP
>> 5. auto-decoding
>> 6. range.save
>> 7. virtual by default
>> 8. ProtoObject
>
> Yeah, pretty much all of these items would be nice to have in my book.
>
>
> [...]
>> The biggest drawback is that we aren't a huge language, with lots of manpower to keep x branches going at once.
>
> Yeah, forking the compiler now may have major unforeseen consequences.
>
> Supporting multiple versions of the language simultaneously will also put a drain on our resources, and there will be tricky issues about how to interoperate code written in different versions of D, but at least it still keeps it all in one place.
>
>
>> I just wanted to throw it out as a discussion point. We spend an awful lot of newsgroup server bytes debating things that to me seem obvious, but have legitimate downsides for not breaking them in a "stable" language.
> [...]
>
> Yes, we're gradually becoming everything we hated about C++. Perhaps it's not as simple to do better, as we once thought! ;-)
>
>
> T

+1 on this comment..
If i could vote for one feature to add that would be HELLA breaking but would be AMAZING at same time it is versioning built into the compiler, preferable GIT because that is what dub uses..

also if we are voting for new names i vote DIALECTIC! A dialectic is what the ancients uses for debate.. hagel used it for dialectic analysis to study things like self vs other, and marx used it for economic analysis, worker vs owner. Often in philosophy classes the dialectic is taught as synonym for debate, that is WRONG... a dialectic is TWO end points with tension between the two. LIKE TWO VERSIONS OF A COMPILER!!! OR TWO VERSIONS OF A REPOSITORY .. or two nodes in a graph...

The tension this language is facing is the fact that old versions of the language can not communicate with new versions of the language.. they can not interact with each other!

The dialectic is often used as a synonym for debate.. if the past version of the compiler and the future versions of the compiler could communicate.. share information.. have a debate.. ideas could flow up and down the stack..

If i could vote for one feature that would be hella breaking but lowkey amazing it would be adding versioning system to the compiler.. where child and parent compilers talked back and forth to compile the code..

On Wednesday, 1 April 2020 at 06:58:47 UTC, Petar Kirov [ZombineDev] wrote:
>
> Small correction: we have a major release every two months - see: https://dlang.org/changelog/release-schedule.html
>
> You can see the history of releases here: https://dlang.org/changelog/index.html

Oops! So not even 2 years of deprecation.
When I tried to follow the deprecation schedule, one of our corporate user complained and this happened: https://github.com/dlang/dmd/pull/10763
Personally I am sympathetic to the situation, and they are not alone. If I remember correctly Weka also had a period where they were not updating their compiler because it was just so much work (although it had more to do with regressions AFAIR).
Personally I'd be in favor of extending the deprecation period for symbols or feature whose replacement hasn't been available for a long time.

On Wednesday, 1 April 2020 at 07:13:53 UTC, Kaitlyn Emmons wrote:
> On Friday, 27 March 2020 at 17:32:44 UTC, H. S. Teoh wrote:

>>
>> What about supporting multiple versions of the language simultaneously, using some kind of version directive at the top of each file?
>
> +1 on this comment..
> If i could vote for one feature to add that would be HELLA breaking but would be AMAZING at same time it is versioning built into the compiler, preferable GIT because that is what dub uses..

static if(__VERSION__ >= 2091) {

}
else {

}

On Wednesday, 1 April 2020 at 07:58:47 UTC, Mike Parker wrote:
> On Wednesday, 1 April 2020 at 07:13:53 UTC, Kaitlyn Emmons wrote:
>> On Friday, 27 March 2020 at 17:32:44 UTC, H. S. Teoh wrote:
>
>>>
>>> What about supporting multiple versions of the language simultaneously, using some kind of version directive at the top of each file?
>>
>> +1 on this comment..
>> If i could vote for one feature to add that would be HELLA breaking but would be AMAZING at same time it is versioning built into the compiler, preferable GIT because that is what dub uses..
>
> static if(__VERSION__ >= 2091) {
>
> }
> else {
>
> }

that is NOT what i am talking about at all.. i am not talking about the code being VERSIONED.. im talking about the COMPILER BEING VERSIONED..

aka if u write something based against an older compiler, it can be translated and passed up the chain to newer compilers

the dialectic can not be resolved by pushing the work off onto the user, you missed the point

On Wednesday, 1 April 2020 at 05:30:41 UTC, Mathias LANG wrote:
> On Tuesday, 31 March 2020 at 23:25:31 UTC, Joseph Rushton Wakeling wrote:
>> Yup, assuming the current 3-month release cadence continues it would make sense to make all breaking changes in only one of those 4 quarterly releases.  A Christmas present to the community? O:-)
>
> That would be a step... Sideways ?
>
> Currently we follow this: https://github.com/dlang/DIPs/blob/5afe088809bed47e45e14c9a90d7e78910ac4054/DIPs/accepted/DIP1013.md

Yup, right.  So however many releases there are in a year (4 quarterly, or 6 bimonthly), the removal schedule is based on the number of releases since something got deprecated.

Now suppose that in 6 different successive releases you deprecate one thing each.  If you follow the 10-releases-later rule then, 10 releases down the line, you wind up with 6 successive releases all making breaking changes.

What I'm suggesting is that instead we could have a once-a-year breaking-change release.  So, if a feature is deprecated, then it gets removed 10 releases later or at the next annual breaking-change point, _whichever is later_.

So, it's a little bit sideways, but it's a lot more predictable and allows dev teams to plan around it much more robustly.  And note that this doesn't shorten deprecation periods -- on average, it will slightly increase them.

Of course, I imagine that in practice where there are multiple breaking changes to make they _do_ get bundled together rather than strictly sticking to a 10-releases-later rule.  But if that's at the discretion of maintainers rather than an official policy, it's a lot less easy to plan around it.

> Personally, the main disruption I had over the last 2 years was the concurrent GC (a new feature) being enabled by default. There was hardly any breaking change.

Sure.  That's why I asked earlier where the breaking changes are coming from.  We can control for when we schedule planned breaking change (and here SemVer is useful).  But if most of the breaking changes are unplanned regressions, we have a different problem.

> With the current 10-release deprecation period and 3-months between release, this means a deprecation is up for 30 months, or 2 1/2 years before being removed. I don't think we should shorten it any further, it already proved problematic on some occasions (e.g. body => do).

Yea, this was inadequate communication on my part.  As explained above, I wasn't suggesting shortening the deprecation period.

On Tuesday, 31 March 2020 at 17:22:34 UTC, Joseph Rushton Wakeling wrote:
> On Tuesday, 31 March 2020 at 17:00:28 UTC, John Colvin wrote:
>> Almost every release would be a major release or a patch release. Hard to see how it adds much value to follow Semantic Versioning in that case.
>
> Well, it might concentrate everyone's minds a bit if we had such a clear indicator of either breaking change or zero new features with every compiler release ... :-)
>
> BTW, _why_ is there such a regular rate of breaking change?  Is it deliberate or accidental?  Assuming deliberate, why so regular?

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.

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.