Future of D 2.x as stable/bug fix, and what's next for D 3.x

[Paul Backus]

On Monday, 31 August 2020 at 20:57:02 UTC, claptrap wrote:
> On Monday, 31 August 2020 at 19:33:45 UTC, H. S. Teoh wrote:
>> On Mon, Aug 31, 2020 at 07:11:40PM +0000, IGotD- via 
>> Digitalmars-d wrote:
>>> On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:
>>>
>> IOW, it's what Andrei has been repeating about adding rather 
>> than changing. Add new versions of the language in the same 
>> compiler, instead of changing the meaning of the current 
>> version of the language.
>
> Could you use a compatibility layer? Say you have a module that 
> is pre safe by default, you could have a component that 
> annotates it so it's safety is explicit and then it can be 
> passed to the new safe by default compiler.
>
> Like the error with ints being truncated on assignment (cant 
> remember what the proper name for it was), you could have a 
> component that just inserts casts where needed, and then it 
> could be passed to the newer compiler.

Yes, this is possible, at least for "normal" code--when you get 
into stuff like mixins and generated code, it becomes more 
complicated. At the very least, it is possible to have the 
compiler print a deprecation warning when it encounters code that 
would have its default changed by the transition. I actually 
implemented a version of this for extern(C) functions [1] and 
used it, along with some Vim macros, to add explicit safety 
annotations to a bunch of declarations in druntime [2].

[1] https://github.com/dlang/dmd/pull/11176
[2] https://github.com/dlang/druntime/pull/3117

> You wouldn't even need compiler versioning, the module could 
> just declare the specific feature it's not updated to yet, and 
> that would cause it to be run through the compatibility 
> process.. Eg..
>
> version(notSafeByDefault);

This is similar to Adam Ruppe's proposal to have blanket-applied 
attributes change the *default* for a particular scope without 
overriding attribute inference for template/auto functions. It's 
an attractive idea, since it allows code to opt-in to 
@safe-by-default (as well as other attributes like 
nothrow-by-default) without breaking compatibility.

I think the main thing stopping it from happening is that 
nobody's stepped forward to write a DIP for it yet. I expect if 
someone did, it would get a favorable reception.