Future of D 2.x as stable/bug fix, and what's next for D 3.x
snarwin at gmail.com
Mon Aug 31 21:58:10 UTC 2020
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  and
used it, along with some Vim macros, to add explicit safety
annotations to a bunch of declarations in druntime .
> 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..
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.
More information about the Digitalmars-d