> No exceptions

Doesn't need to be an edition, its not an either/or situation.

> Change class ABI (monitor) and/or hierarchy

Instead of changing Object I have proposed that we introduce custom roots. Then people use whatever fits their needs.

---

I'm happy to see the change to an integer for editions.

I do want to see D2 (version 2) to be defined as missing DIP1000 enforcement.

There is missing all of the release scheduling as well as a guarantee of when an edition is made. It shouldn't be done yearly (see languages like Rust or C#).

It would also be nice to see a work in progress edition which includes all the currently approved preview flags, so that people can get a feel of what the next edition is going to be like (find bugs ext.).

On Thursday, 30 May 2024 at 18:43:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
> > No exceptions
>
> Doesn't need to be an edition, its not an either/or situation.
>
> > Change class ABI (monitor) and/or hierarchy
>
> Instead of changing Object I have proposed that we introduce custom roots. Then people use whatever fits their needs.
>
> ---
>
> I'm happy to see the change to an integer for editions.
>
> I do want to see D2 (version 2) to be defined as missing DIP1000 enforcement.
>
> There is missing all of the release scheduling as well as a guarantee of when an edition is made. It shouldn't be done yearly (see languages like Rust or C#).
>
> It would also be nice to see a work in progress edition which includes all the currently approved preview flags, so that people can get a feel of what the next edition is going to be like (find bugs ext.).

That would be the `-edition=2024` switch. I don't think the edition needs to be finalised before we introduce the compiler switch.

On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:
> https://github.com/atilaneves/DIPs/blob/editions/editions.md
>
> Destroy!

> Templates would obey the rules of the edition of the module they are defined in, not the module where they are instantiated.

Including mixin templates?

Atila Neves kirjoitti 30.5.2024 klo 21.31:
> https://github.com/atilaneves/DIPs/blob/editions/editions.md
> 
> Destroy!

I suggest a different syntax. I think it should be something that would lend itself to enabling/disabling individual features (compiler switches) module-wise.

I'm not necessarily arguing we should make our current compiler switches capable of being turned on or off module by module, just that if we decided to to that, we could use the same syntax to do it. Therefore, a decimal without any keywords is probably bad.

Version specifications are IMO a good tool for this. Just like the proposed edition declarations, a specification is local to the module.

```D
module core.atomic;
version = D_2024;
/+ If we decided to allow it, this
   syntax would work for compiler switches
   (although we'd probably need a version
   specification for the reverse setting
   too)
+/
version = D_NoBoundsChecks;
```

Another possibility is pragmas. This is what Haskell, or more precisely it's Glasgow compiler does to accomplish the same. I also think it's per-module extension would be well worth putting to "prior work" section (and investigating if you haven't already).

Another issue, that doesn't strictly affect the design of this DIP but should be given cosideration as soon as it's used for enabling features selectively. Suppose `@safe` is the default for edition 2026 but the present rules apply for edition 2024. What should happen in this case?

```D
#line 1 "modulea.d"
module modulea 2024;

template T(int i)
{   // No explicit attributes.
    // Note, no auto inference, because only eponymous
    // functions inside a template get auto-inference.
    int incr(int j) => i + j;
}

#line 1 "moduleb.d"
module moduleb 2026;
import modulea;

//Defined within edition 2024, but instantiated within edition 2026.
//@safe or @system?
//I quess @system but I want to read your opinion.
alias incr = T!(3).incr;
```

As a whole, I'm highly receptive to this DIP.