D Editions

[Dukc]

On Tuesday, 14 January 2025 at 05:27:10 UTC, Paul Backus wrote:
> On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:
>> https://github.com/atilaneves/DIPs/blob/editions/editions.md
>>
>> Destroy!
>
> My opinion on this remains the same as it was when I wrote 
> ["Thoughts on Backward Compatibility"][1]; to wit:
>
> * Even without an edition bump, small-scale breaking changes 
> with easy migration paths aren't a big deal.
> * Even with an edition bump, large-scale breaking changes that 
> make migration difficult should probably be avoided.
>
> In other words: the presence of editions in a language does not 
> really make a difference w.r.t. which kinds of breaking changes 
> are feasible to introduce.
>
> Since the stated purpose of editions is to make it easier to 
> introduce breaking changes, I believe that this flaw renders 
> the entire proposal unfit for purpose.

I have hard time believing the real world is so black-and-white 
with regards to change disruptiveness that editions wouldn't even 
make a difference. I don't really buy that there are no 
"medium-breakage" changes. But even if that was the case, 
editions do soften the blow when large changes have just too much 
benefits to ignore, or have to be made due to existing problems.

DIP1000 or whatever will come in it's stead is a good example, 
unless we leave that memory safety hole unplugged forever. I 
think you're at least somewhat right in the linked thread that 
the fix should have community buy-in, but I feel the reverse is 
also the case - decision to ignore the flaw would also require as 
much buy-in if not more so, since it'd be abandoning the vision 
and hope of memory-safe D that we have so far.