www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Editions Ideas

reply Walter Bright <newshound2 digitalmars.com> writes:
Now that Editions have been implemented (thanks Atila, Dennis, and Rikki) it's 
time to solicit D features to be dropped from the next Edition of D.

I'll start by eliminating -revert=intpromote
Dec 12
next sibling parent reply bauss <jacobbauss gmail.com> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.

 I'll start by eliminating -revert=intpromote


I'm out of the loop, what exactly is "Editions"? :)
Dec 12
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 13/12/2025 12:10 PM, bauss wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, and 
 Rikki) it's time to solicit D features to be dropped from the next 
 Edition of D.

 I'll start by eliminating -revert=intpromote


 
 I'm out of the loop, what exactly is "Editions"? :)


A way to version the language on a per module basis so that we can break 
code, while allowing old code to continue compiling.

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1052.md
Dec 12
parent bauss <jacobbauss gmail.com> writes:
On Saturday, 13 December 2025 at 01:18:57 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 13/12/2025 12:10 PM, bauss wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright 
 wrote:

 Now that Editions have been implemented (thanks Atila, 
 Dennis, and Rikki) it's time to solicit D features to be 
 dropped from the next Edition of D.

 I'll start by eliminating -revert=intpromote


 
 I'm out of the loop, what exactly is "Editions"? :)


 A way to version the language on a per module basis so that we 
 can break code, while allowing old code to continue compiling.

 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1052.md


Oh that is amazing
Dec 12
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.


-preview=dip1000
Dec 12
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 13/12/2025 2:21 PM, Paul Backus wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, and 
 Rikki) it's time to solicit D features to be dropped from the next 
 Edition of D.


 
 -preview=dip1000


You are about 8 hours too late.

All the inferrable attributes are meant to be getting their 
implementation replaced with "the slow DFA" :)

The original implementations will stick around for the older editions 
that don't have the replacement.

Exactly how it all gets turned on/off is yet to be decided, depends on 
how the slow DFA in question works out.
Dec 12
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, December 12, 2025 6:21:24 PM Mountain Standard Time Paul Backus
via Digitalmars-d wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis,
 and Rikki) it's time to solicit D features to be dropped from
 the next Edition of D.


 -preview=dip1000


Given that you don't like DIP 1000 as it stands, I assume that you mean that
you want DIP 1000 removed and not that you want the preview switch to be
removed in favor of making it the default behavior.

Regardless, in the DLF meeting this morning, it was decided that we're not
going to be going forward with DIP 1000 as it stands. Walter acknowledged
that too many folks would consider the explicit attributes it requires to be
unacceptable. Now, he wants to look into using full program analysis to
infer them instead of having an explicit scope attributes be used for it.
That's obviously going to have issue with cases where separate compilation
is required, and it's potentially going to cause problems where
implementation details of a library then affect the code using them (though
in general, it's obviously a serious issue if a library which wasn't
escaping a reference then silently starts escaping it). So, what's actually
going to happen instead is very much an open question, but DIP 1000 will not
be becoming the default with the first Edition (or any Edition unless a
different decision is made in the future).

- Jonathan M Davis
Dec 12
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis 
wrote:

 Regardless, in the DLF meeting this morning, it was decided 
 that we're not going to be going forward with DIP 1000 as it 
 stands. Walter acknowledged that too many folks would consider 
 the explicit attributes it requires to be unacceptable. Now, he 
 wants to look into using full program analysis to infer them 
 instead of having an explicit scope attributes be used for it.


So, in other words, we are still moving forward with the overall 
design of DIP 1000, but we are reworking the implementation to be 
more effective.

I do not think this is the right course of action. I think DIP 
1000 should be torn out of the language completely, root and 
branch. I am happy to write up my thoughts on this at length if 
anyone is interested in reading them.
Dec 13
next sibling parent reply drug007 <drug2004 bk.ru> writes:
On 13.12.2025 17:41, Paul Backus wrote:

 On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis wrote:

 Regardless, in the DLF meeting this morning, it was decided that we're 
 not going to be going forward with DIP 1000 as it stands. Walter 
 acknowledged that too many folks would consider the explicit 
 attributes it requires to be unacceptable. Now, he wants to look into 
 using full program analysis to infer them instead of having an 
 explicit scope attributes be used for it.


 
 So, in other words, we are still moving forward with the overall design 
 of DIP 1000, but we are reworking the implementation to be more effective.
 
 I do not think this is the right course of action. I think DIP 1000 
 should be torn out of the language completely, root and branch. I am 
 happy to write up my thoughts on this at length if anyone is interested 
 in reading them.


I'm interested. I haven't used dip1000, but I have the impression it is 
a controversial feature leading to long-running debate. I don't have my 
own opinion and I would be happy to receive more information in addition 
to the rather poor documentation available.
Dec 13
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2025 6:51 AM, drug007 wrote:

 I'm interested. I haven't used dip1000, but I have the impression it is a 
 controversial feature leading to long-running debate. I don't have my own 
 opinion and I would be happy to receive more information in addition to the 
 rather poor documentation available.


It's entire purpose is simple - preventing a pointer from "escaping" a function 
that it is passed to. This is used to:

1. prevent a live pointer into an expired stack frame

2. prevent a live pointer into allocated memory that has been free'd
Dec 13
prev sibling next sibling parent matheus <matheus gmail.com> writes:
On Saturday, 13 December 2025 at 14:41:52 UTC, Paul Backus wrote:

 On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis 
 wrote:

 Regardless, in the DLF meeting this morning, it was decided 
 that we're not going to be going forward with DIP 1000 as it 
 stands. Walter acknowledged that too many folks would consider 
 the explicit attributes it requires to be unacceptable. Now, 
 he wants to look into using full program analysis to infer 
 them instead of having an explicit scope attributes be used 
 for it.


 So, in other words, we are still moving forward with the 
 overall design of DIP 1000, but we are reworking the 
 implementation to be more effective.

 I do not think this is the right course of action. I think DIP 
 1000 should be torn out of the language completely, root and 
 branch. I am happy to write up my thoughts on this at length if 
 anyone is interested in reading them.


Please do.

Matheus.
Dec 13
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 13 December 2025 at 14:41:52 UTC, Paul Backus wrote:

 On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis 
 wrote:

 [...]


 So, in other words, we are still moving forward with the 
 overall design of DIP 1000, but we are reworking the 
 implementation to be more effective.

 I do not think this is the right course of action. I think DIP 
 1000 should be torn out of the language completely, root and 
 branch. I am happy to write up my thoughts on this at length if 
 anyone is interested in reading them.



 anyone


does that include my morbid curiosity?
Dec 13
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Saturday, 13 December 2025 at 14:41:52 UTC, Paul Backus wrote:

 I am happy to write up my thoughts on this at length if anyone 
 is interested in reading them.


Certainly! You always formulate your thoughts very well.
Dec 13
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 13 December 2025 at 14:41:52 UTC, Paul Backus wrote:

 On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis 
 wrote:

 Regardless, in the DLF meeting this morning, it was decided 
 that we're not going to be going forward with DIP 1000 as it 
 stands. Walter acknowledged that too many folks would consider 
 the explicit attributes it requires to be unacceptable. Now, 
 he wants to look into using full program analysis to infer 
 them instead of having an explicit scope attributes be used 
 for it.


 So, in other words, we are still moving forward with the 
 overall design of DIP 1000, but we are reworking the 
 implementation to be more effective.

 I do not think this is the right course of action. I think DIP 
 1000 should be torn out of the language completely, root and 
 branch. I am happy to write up my thoughts on this at length if 
 anyone is interested in reading them.


I’d be interested in reading them.

I’ve written some DIP1000 aware code and it was a bit painful, 
but I appreciated the effort into thinking about memory safety 
without GC.

My take is generally that D gets into trouble with half-baked 
ideas that aren’t fully expressive, but are chosen to avoid 
breaking code. Something like editions gives the freedom to 
choose a better foundation.

All else equal, I would recommend trying to more closely follow 
what Rust has done, particularly with respect to lifetimes, since 
that has traction in the marketplace. I also have found the 
arguments for an isolated type to be strong.
Dec 13
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2025 9:45 AM, jmh530 wrote:

 All else equal, I would recommend trying to more closely follow what Rust has 
 done, particularly with respect to lifetimes, since that has traction in the 
 marketplace. I also have found the arguments for an isolated type to be strong.


Lifetimes are what the dip1000 annotations do.
Dec 13
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 14 December 2025 at 06:49:14 UTC, Walter Bright wrote:

 On 12/13/2025 9:45 AM, jmh530 wrote:

 All else equal, I would recommend trying to more closely 
 follow what Rust has done, particularly with respect to 
 lifetimes, since that has traction in the marketplace. I also 
 have found the arguments for an isolated type to be strong.


 Lifetimes are what the dip1000 annotations do.


My broader point was that one clearly has gained more market 
share than the other. I think the cognitive load of Rust’s 
lifetime rules is lower than DIP 1000. The nice thing about 
Dip1000 is that it made scope actually do something, but the 
whole system requires keeping more in your head than Rust’s.

Lifetimes are as it relates to DIP1000, but the ownership system 
is probably as important for Rust’s popularity. You tried  live 
for ownership and I think that’s got much more pushback than 
DIP1000.
Dec 14
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 3:55 AM, jmh530 wrote:

 Lifetimes are as it relates to DIP1000, but the ownership system is probably
as 
 important for Rust’s popularity. You tried  live for ownership and I think 
 that’s got much more pushback than DIP1000.


I deliberately designed the  live feature to not require any annotations. And
it 
worked!

It's still a prototype, though, because nobody wanted it and so development
came 
to an end with it.
Dec 14
parent reply Mike Shah <mshah.475 gmail.com> writes:
On Sunday, 14 December 2025 at 20:16:34 UTC, Walter Bright wrote:

 On 12/14/2025 3:55 AM, jmh530 wrote:

 Lifetimes are as it relates to DIP1000, but the ownership 
 system is probably as important for Rust’s popularity. You 
 tried  live for ownership and I think that’s got much more 
 pushback than DIP1000.


 I deliberately designed the  live feature to not require any 
 annotations. And it worked!

 It's still a prototype, though, because nobody wanted it and so 
 development came to an end with it.


 live is an underrated feature, I'm a fan and it's something that 
I occasionally use for its simplicity. Sometimes I toss  live, 
 safe, etc. on functions to see that state of my code to see if 
the compiler can help me refactor library code.
Dec 14
next sibling parent Dukc <ajieskola gmail.com> writes:
On Monday, 15 December 2025 at 04:20:21 UTC, Mike Shah wrote:

  live is an underrated feature, I'm a fan and it's something 
 that I occasionally use for its simplicity.


Can you provide examples? I personally consider it almost 
useless, but I'd like someone to prove me wrong.
Dec 15
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 8:20 PM, Mike Shah wrote:

  live is an underrated feature, I'm a fan and it's something that I
occasionally 
 use for its simplicity. Sometimes I toss  live,  safe, etc. on functions to
see 
 that state of my code to see if the compiler can help me refactor library code.


Thank you! You're the first!
Dec 15
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 14 December 2025 at 06:49:14 UTC, Walter Bright wrote:

 On 12/13/2025 9:45 AM, jmh530 wrote:

 All else equal, I would recommend trying to more closely 
 follow what Rust has done, particularly with respect to 
 lifetimes, since that has traction in the marketplace. I also 
 have found the arguments for an isolated type to be strong.


 Lifetimes are what the dip1000 annotations do.


Yes, but Rust's lifetimes are more flexible than dip1000's 
lifetimes, and allow code to be written in a more intuitive way.

For example, it is impossible with dip1000 to declare two 
variables with exactly the same lifetime as each other, even if 
they are contain the same value. To work around this, you have to 
combine the two variables into a single value, like a tuple or a 
static array--which makes the code less natural to read.
Dec 14
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 15/12/2025 1:28 AM, Paul Backus wrote:

 On Sunday, 14 December 2025 at 06:49:14 UTC, Walter Bright wrote:

 On 12/13/2025 9:45 AM, jmh530 wrote:

 All else equal, I would recommend trying to more closely follow what 
 Rust has done, particularly with respect to lifetimes, since that has 
 traction in the marketplace. I also have found the arguments for an 
 isolated type to be strong.


 Lifetimes are what the dip1000 annotations do.


 
 Yes, but Rust's lifetimes are more flexible than dip1000's lifetimes, 
 and allow code to be written in a more intuitive way.
 
 For example, it is impossible with dip1000 to declare two variables with 
 exactly the same lifetime as each other, even if they are contain the 
 same value. To work around this, you have to combine the two variables 
 into a single value, like a tuple or a static array--which makes the 
 code less natural to read.


To demonstrate that:

```d
     scope int* a;
     {
         scope int* b = new int;
         scope int* c = new int;
         b = c; // Error: scope variable `c` assigned to `b` with longer 
lifetime
         a = c; // Error: scope variable `c` assigned to `a` with longer 
lifetime
     }
```

b and c should have the same lifetime to scope when it comes to 
assignments like this. There is no taking a pointer to anything.

However we don't need Rust's approach to annotating it, which functions 
as a constraint.

This can be done using scope/return and  escape.

I.e.

```rust
// `<'a: 'b, 'b>` reads as lifetime `'a` is at least as long as `'b`.
// Here, we take in an `&'a i32` and return a `&'b i32` as a result of 
coercion.
fn choose_first<'a: 'b, 'b>(first: &'a i32, _: &'b i32) -> &'b i32 {
     first
}
```

becomes

```d
ref int choose_first( escape(return&) ref int* first, ref int* _) {
	return a;
}
```

or simplified (with default ref + ref = &):


```d
ref int choose_first(return ref int* first, ref int* _) {
	return a;
}
```
Dec 14
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 4:57 AM, Richard (Rikki) Andrew Cattermole wrote:

 ```d
      scope int* a;
      {
          scope int* b = new int;
          scope int* c = new int;
          b = c; // Error: scope variable `c` assigned to `b` with
longer lifetime
          a = c; // Error: scope variable `c` assigned to `a` with
longer lifetime
      }
 ```
 
 b and c should have the same lifetime to scope when it comes to assignments
like 
 this. There is no taking a pointer to anything.


I don't see much point to justify the added complexity.
Dec 14
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 4:28 AM, Paul Backus wrote:

 Yes, but Rust's lifetimes are more flexible than dip1000's lifetimes, and
allow 
 code to be written in a more intuitive way.
 
 For example, it is impossible with dip1000 to declare two variables with
exactly 
 the same lifetime as each other, even if they are contain the same value. To 
 work around this, you have to combine the two variables into a single value, 
 like a tuple or a static array--which makes the code less natural to read.


I'm aware of that, and in my looking into Rust it seemed like that feature was 
very rarely needed.
Dec 14
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2025 6:41 AM, Paul Backus wrote:

 I think DIP 1000 should be 
 torn out of the language completely, root and branch.


Other languages are moving towards memory safety. Need to keep improving the 
memory safety of D.
Dec 13
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 14 December 2025 at 06:48:05 UTC, Walter Bright wrote:

 On 12/13/2025 6:41 AM, Paul Backus wrote:

 I think DIP 1000 should be torn out of the language 
 completely, root and branch.


 Other languages are moving towards memory safety. Need to keep 
 improving the memory safety of D.


We can (and should) improve memory safety by closing holes in 
 safe. For example, instead of using -preview=dip1000 we can 
simply forbid  safe code from taking the address of a 
stack-allocated variable (passing by `ref` is fine though).
Dec 14
next sibling parent Derek Fawcus <dfawcus+dlang employees.org> writes:
On Sunday, 14 December 2025 at 11:44:32 UTC, Paul Backus wrote:

 For example, instead of using -preview=dip1000 we can simply 
 forbid  safe code from taking the address of a stack-allocated 
 variable (passing by `ref` is fine though).


Not for me.  I prefer passing by pointer, including of stack 
variables.

That simply because it makes it explicit at the call site that a 
reference has been made, and provided to the called routine.

Hence one is able to comprehend the potential effects of a call 
using local knowledge only.

Thus why I actually liked the addition of the scope qualifier to 
re-enable such explicit pointer passes in  safe code.

DF
Dec 14
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 3:44 AM, Paul Backus wrote:

 We can (and should) improve memory safety by closing holes in  safe. For 
 example, instead of using -preview=dip1000 we can simply forbid  safe code
from 
 taking the address of a stack-allocated variable (passing by `ref` is fine
though).


Then you cannot have arrays on the stack, which are a highly useful construct
(I 
use them all the time).
Dec 14
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Sunday, 14 December 2025 at 20:23:51 UTC, Walter Bright wrote:

 Then you cannot have arrays on the stack, which are a highly 
 useful construct (I use them all the time).


 trusted doesn't solve this?
Dec 14
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 2:13 PM, Sergey wrote:

  trusted doesn't solve this?


The idea is to make as much code  safe as practical.
Dec 17
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, December 14, 2025 1:23:51 PM Mountain Standard Time Walter Bright
via Digitalmars-d wrote:

 On 12/14/2025 3:44 AM, Paul Backus wrote:

 We can (and should) improve memory safety by closing holes in  safe. For
 example, instead of using -preview=dip1000 we can simply forbid  safe code from
 taking the address of a stack-allocated variable (passing by `ref` is fine
though).


 Then you cannot have arrays on the stack, which are a highly useful construct
(I
 use them all the time).


There's an enormous difference between not being able to do something and
not being able to do something in  safe code.

You can have arrays on the stack just fine. It's just that slicing them has
to be  trusted, because you have to ensure that the resulting dynamic array
doesn't outlive the static array, and the compiler can't do that without
some sort of lifetime tracking. The fact that slicing a static array is not
currently treated as  system is a hole in  safe, and it should have been
fixed by making it an error years ago, but instead, you decided to put that
off in favor of fixing it with DIP 1000. So, we've had this hole in  safe
for years when what we should have done is close the hole. We can improve
the language later if we can come up with a way to track escaping references
in a sane manner, but IMHO, that's no reason to leave a hole in  safe while
we don't have that solution.

There really isn't a difference between using & on a variable and using []
on a static array except that you get the length along with the pointer, and
they should be treated the same.

The first edition is a prime time to close all of the known holes in  safe,
which includes anything involving static arrays - be it explicit or with
features like typesafe variadic arrays which are actually implemented as
slices of static arrays. IMHO, putting off fixing holes in  safe just
because we don't want to "break" someone's code makes  safe borderline
meaningless. We need to close the holes. With Editions, we can choose to do
that by restricting such changes to new Editions rather than fixing them as
soon as we find them, but we need to stop leavin these holes open.

That does not preclude improving the language later and making  safe apply
to more as we're able to do so, but we should not leave holes in  safe just
because we don't like the fact that we can't currently guarantee that
something is memory safe.

- Jonathan M Davis
Dec 14
next sibling parent Dukc <ajieskola gmail.com> writes:
On Monday, 15 December 2025 at 04:41:39 UTC, Jonathan M Davis 
wrote:

 That does not preclude improving the language later and making 
  safe apply to more as we're able to do so, but we should not 
 leave holes in  safe just because we don't like the fact that 
 we can't currently guarantee that something is memory safe.

 - Jonathan M Davis


Actually, maybe that's a good solution for the next edition. You 
can't return a slice of a static array, or a pointer to a struct 
field in stack anymore, except if you use DIP1000. Without the 
switch, you have Roberts Simple Safe D[1]. With the switch on, 
you'll have DIP1000. In either case, you'll have to deal with 
lots of breakage. If you want to wait for a better solution 
before breaking your code, you can stick with the older edition.

Then we'll see which solution people really prefer.

[1]: Well actually it's a bit more permissive than Roberts 
proposal. Robert proposed no returning by ref, but actually you 
can safely return by ref even without dip1000 as long as you have 
dip25, which is already enabled by default. It's only taking 
addresses or slices of local struct/union fields and static 
arrays which needs dip1000 for safety.
Dec 15
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
A difference between slices and pointers - a pointer can have any offset, while 
a slice is bounds checked.

I know that is not the thrust of your argument, just thought I would point that
out.

As far as safety goes, taking a slice of a stack array is the same as taking a 
pointer to a stack variable, and you are correct about that.

We could, perhaps, do something like:

```
int[10] array = ...;
ref int[] slice = array[4 .. 5];
```
and then the `ref` semantics would apply. It may be something worth exploring.

In the meantime, taking a slice to a stack array would attach `scope` to its 
lvalue. If that cannot be done (if the lvalue is not a symbol), then it would
be 
an error.
Dec 17
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, December 13, 2025 7:41:52 AM Mountain Standard Time Paul Backus
via Digitalmars-d wrote:

 On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis
 wrote:

 Regardless, in the DLF meeting this morning, it was decided
 that we're not going to be going forward with DIP 1000 as it
 stands. Walter acknowledged that too many folks would consider
 the explicit attributes it requires to be unacceptable. Now, he
 wants to look into using full program analysis to infer them
 instead of having an explicit scope attributes be used for it.


 So, in other words, we are still moving forward with the overall
 design of DIP 1000, but we are reworking the implementation to be
 more effective.

 I do not think this is the right course of action. I think DIP
 1000 should be torn out of the language completely, root and
 branch.


IMHO, this is a big win, because it means that DIP 1000 as it stands is not
happening. I do have concerns about trying to take DIP 1000 and
automatically infer it with full program analysis, and honestly, I don't
expect that that's going to be a reasonable solution regardless of how well
DIP 1000 models things, because it's going to pose a serious problem with
libraries (since it potentially means that the  safety of the caller depends
on implementation details of the library which the library author made no
promises about), but I think that agreeing to not make DIP 1000 as it stands
be enabled by a default is a big step in the right direction.

I would like to see a better approach with whatever we do going forward, but
if it's as bad as it looks like it's probably going to be, it's not going to
ever make it into the language proper anyway.


 I am happy to write up my thoughts on this at length if
 anyone is interested in reading them.


I suggest that you do.

- Jonathan M Davis
Dec 14
prev sibling next sibling parent reply Derek Fawcus <dfawcus+dlang employees.org> writes:
On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis 
wrote:

 Now, he wants to look into using full program analysis to infer 
 them instead of having an explicit scope attributes be used for 
 it.


Quite apart from precluding separate compilation, the other issue 
would be where one wishes to ensure a given behaviour occurs.

The difference between requiring annotation, vs having them as 
optional in order to ensure a given output.  i.e. having them as 
optional things so force a given effect, as opposed to inferring 
the intent from potentially buggy code.

Essentially, code could have an error, and a behaviour inferred 
due to the inability to express / enforce a specific behaviour.

That has always been one of my issues with C++, too much can be 
inferred from how baroque it is.

DF
Dec 13
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/12/2025 5:48 AM, Derek Fawcus wrote:

 On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis wrote:
 
     Now, he wants to look into using full program analysis to infer them
     instead of having an explicit scope attributes be used for it.
 
 Quite apart from precluding separate compilation, the other issue would 
 be where one wishes to ensure a given behaviour occurs.


I'm aware of separate compilation problem, it will be solved one way or 
another.

I made sure it was discussed even if others didn't quite understand the 
importance of it being solved.
Dec 13
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 13 December 2025 at 04:18:08 UTC, Jonathan M Davis 
wrote:

 Walter acknowledged that too many folks would consider the 
 explicit attributes it requires to be unacceptable. Now, he 
 wants to look into using full program analysis to infer them 
 instead of having an explicit scope attributes be used for it. 
 That's obviously going to have issue with cases where separate 
 compilation is required, and it's potentially going to cause 
 problems where implementation details of a library then affect 
 the code using them (though in general, it's obviously a 
 serious issue if a library which wasn't escaping a reference 
 then silently starts escaping it).


I also sometimes think dip1000 needs to be more *manual*, not 
more automatic. I see it can sure be confusing when the compiler 
says something is `scope` that you didn't designate as such. This 
happens to a local variable that's declared earlier if you assign 
it to something that needs the storage class.
Dec 15
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 15/12/2025 11:25 PM, Dukc wrote:

 I see it can sure be confusing when the compiler says something is | 
 scope| that you didn't designate as such


The inference isn't the problem here.

The issue is DIP1000 cannot trace why it thinks this and give pretty 
output explaining it.

The fast DFA engine also suffers from it, but I will be fixing that 
eventually. I want the main features to be all in before tackling the 
tracing.
Dec 15
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2025 2:25 AM, Dukc wrote:

 I also sometimes think dip1000 needs to be more *manual*, not more automatic.
I 
 see it can sure be confusing when the compiler says something is `scope` that 
 you didn't designate as such. This happens to a local variable that's declared 
 earlier if you assign it to something that needs the storage class.


When an error message is confusing, by far the most practical method to figure 
it out is to:

1. copy the file to a new file, save the original

2. delete code until the message goes away

3. revert to the previous version that still produced the error

4. goto step 2, and delete something else

5. continue until you have the minimum piece of code the generates the error

This usually clears up the understanding of the issue.

The D "dustmite" program can do this automatically.

https://github.com/CyberShadow/DustMite

Recently, I was handed a program with a baffling dip1000 error in it. I noticed 
it was loaded with templates, conditional compilation, irrelevant functions,
and 
complex declarations.

Deleting all that fluff out of it led directly to the problem.

This is the most powerful debugging technique I know of. I use it all the time.
Dec 17
prev sibling next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.

 I'll start by eliminating -revert=intpromote


autoenconding for sure

also people were talking about removing monitor from Object
Dec 13
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 13 December 2025 at 09:37:21 UTC, Sergey wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright 
 wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.

 I'll start by eliminating -revert=intpromote


 autoenconding for sure


I think that’s more of a Phobos v3 issue than editions.
Dec 13
parent monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 13 December 2025 at 17:47:21 UTC, jmh530 wrote:

 On Saturday, 13 December 2025 at 09:37:21 UTC, Sergey wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright 
 wrote:

 Now that Editions have been implemented (thanks Atila, 
 Dennis, and Rikki) it's time to solicit D features to be 
 dropped from the next Edition of D.

 I'll start by eliminating -revert=intpromote


 autoenconding for sure


 I think that’s more of a Phobos v3 issue than editions.


it could be a version thing, then a lazy edit fixing phoboes v2
Dec 13
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2025 1:37 AM, Sergey wrote:

 autoenconding for sure


I think you meant autodecoding, and I agree. But that's a Phobos library issue, 
and Adam Wilson and Co. are working hard on that.
Dec 13
prev sibling next sibling parent reply Dom Disc <dominikus scherkl.de> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.

 I'll start by eliminating -revert=intpromote


- unitary operators NOT modifying the type of their operand
   (e.g. given "ubyte i", I want +i, -i, ~i and even !i to be an 
ubyte).
Dec 13
next sibling parent Dom Disc <dominikus scherkl.de> writes:
On Saturday, 13 December 2025 at 10:18:30 UTC, Dom Disc wrote:

 - unitary operators NOT modifying the type of their operand


And if you want something changing the type of the operand, then 
define

Unsigned!T abs(T)(T v) => cast(Unsigned!T)(v<0 ? -v : v);

(fixing the long standing bug that abs(int.min) < 0)
Together with the above change this would also rectify why abs is 
not an unary operator.
Dec 13
prev sibling parent reply Dom Disc <dominikus scherkl.de> writes:
On Saturday, 13 December 2025 at 10:18:30 UTC, Dom Disc wrote:

 - unitary operators NOT modifying the type of their operand


By the way, why the f*** is cast(bool)nan == true ?!?
This should also be fixed.
Dec 13
next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 13 December 2025 at 14:50:16 UTC, Dom Disc wrote:

 On Saturday, 13 December 2025 at 10:18:30 UTC, Dom Disc wrote:

 - unitary operators NOT modifying the type of their operand




I think this thread is supposed to be about 'features to be 
dropped', not about changing the types of things. That would 
silently break code when upgrading to a new edition.


 By the way, why the f*** is cast(bool)nan == true ?!?
 This should also be fixed.


No:


 Fundamental types are true when non-zero


https://dlang.org/spec/statement.html#boolean-conditions
Dec 13
parent reply Dom Disc <dominikus scherkl.de> writes:
On Saturday, 13 December 2025 at 15:41:52 UTC, Nick Treleaven 
wrote:

 On Saturday, 13 December 2025 at 14:50:16 UTC, Dom Disc wrote:

 By the way, why the f*** is cast(bool)nan == true ?!?
 This should also be fixed.


 No:


 Fundamental types are true when non-zero


 https://dlang.org/spec/statement.html#boolean-conditions


Then the documentation should be fixed also. I can't imagine a 
situation where it would be useful to associate nan with any kind 
of truth. Change the spec to
"Fundamental types are true if they are valid and non-zero."

And wasn't the whole idea of editions to be able to make breaking 
changes? If you don't like the changes, you can stay with the 
current behavior.

And I consider integer-propagation a feature worthy of being 
dropped. And unary operators changing the type of its operand is 
part of this "feature".
Dec 13
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2025 8:10 PM, Dom Disc wrote:

 And I consider integer-propagation a feature worthy of being dropped. And
unary 
 operators changing the type of its operand is part of this "feature".


The idea is to compile C-like code without silently breaking it.
Dec 13
parent reply Dom Disc <dominikus scherkl.de> writes:
On Sunday, 14 December 2025 at 06:51:33 UTC, Walter Bright wrote:

 On 12/13/2025 8:10 PM, Dom Disc wrote:

 And I consider integer-propagation a feature worthy of being 
 dropped. And unary operators changing the type of its operand 
 is part of this "feature".


 The idea is to compile C-like code without silently breaking it.


Not changing the operand type doesn't break C code, as C also 
didn't change the operand type.
Dec 14
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 5:22 AM, Dom Disc wrote:

 Not changing the operand type doesn't break C code, as C also didn't change
the 
 operand type.


C promotes bytes to ints before doing a unary operation on them.
Dec 14
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2025 6:50 AM, Dom Disc wrote:

 By the way, why the f*** is cast(bool)nan == true ?!?


It's the IEEE754 floating point standard behavior. NaN is never equal to 
anything else, so cast(bool)NaN is lowered to NaN!=0, which is true.


 This should also be fixed.


IEEE754 compliance is both expected and baked into the CPU hardware.
Dec 13
parent reply Dom Disc <dominikus scherkl.de> writes:
On Sunday, 14 December 2025 at 07:00:33 UTC, Walter Bright wrote:

 On 12/13/2025 6:50 AM, Dom Disc wrote:

 By the way, why the f*** is cast(bool)nan == true ?!?


 It's the IEEE754 floating point standard behavior. NaN is never 
 equal to anything else, so cast(bool)NaN is lowered to NaN!=0, 
 which is true.


NaN > 0 is false and NaN <= 0 is also false.
One can see this as a contradiction, but it isn't.
So why can not also NaN == 0 and NaN != 0 both be false?
I would consider this IEEE754 compliant.


 IEEE754 compliance is both expected and baked into the CPU 
 hardware.


Yup. But it only requires NaN == 0 to be false. It doesn't talk 
about NaN != 0 at all.
Dec 14
next sibling parent reply Dom Disc <dominikus scherkl.de> writes:
On Sunday, 14 December 2025 at 13:27:19 UTC, Dom Disc wrote:

 NaN > 0 is false and NaN <= 0 is also false.
 One can see this as a contradiction, but it isn't.
 So why can not also NaN == 0 and NaN != 0 both be false?
 I would consider this IEEE754 compliant.


I mean, the rule is really easy: Simply any comparison involving 
NaN should result in false. Only the result of the comparison can 
be further processed as boolean expression.

Consider this:

```d
if(a!=a) { /*kill your harddisk*/ }
```

Would you expect this code to ever be executed?

But if you set float a = NaN, then it will!
We should avoid this.
Dec 14
next sibling parent Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 14 December 2025 at 13:43:55 UTC, Dom Disc wrote:

 On Sunday, 14 December 2025 at 13:27:19 UTC, Dom Disc wrote:

 NaN > 0 is false and NaN <= 0 is also false.
 One can see this as a contradiction, but it isn't.
 So why can not also NaN == 0 and NaN != 0 both be false?
 I would consider this IEEE754 compliant.


 I mean, the rule is really easy: Simply any comparison 
 involving NaN should result in false. Only the result of the 
 comparison can be further processed as boolean expression.

 Consider this:

 ```d
 if(a!=a) { /*kill your harddisk*/ }
 ```

 Would you expect this code to ever be executed?

 But if you set float a = NaN, then it will!
 We should avoid this.


This is how you check for NaN though. How do you check for Nan 
without it?
Dec 14
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 14 December 2025 at 13:43:55 UTC, Dom Disc wrote:

 On Sunday, 14 December 2025 at 13:27:19 UTC, Dom Disc wrote:

 NaN > 0 is false and NaN <= 0 is also false.
 One can see this as a contradiction, but it isn't.
 So why can not also NaN == 0 and NaN != 0 both be false?
 I would consider this IEEE754 compliant.


 I mean, the rule is really easy: Simply any comparison 
 involving NaN should result in false. Only the result of the 
 comparison can be further processed as boolean expression.

 Consider this:

 ```d
 if(a!=a) { /*kill your harddisk*/ }
 ```

 Would you expect this code to ever be executed?

 But if you set float a = NaN, then it will!
 We should avoid this.


When they say they are ieeeeeeee floats they are definition is 
that wild stupidity, specs are just written by people and 
sometimes those people were idiots 60 years ago.

Hense why Im anti spec, specs are in practice where hard to fix 
bugs get defined as correct *in authoritative lawyeristic 
verbosity* in the wrong section. This float behavior belongs with 
a number trait or by the opoverloads with no implied authorithy 
its correct or desired. Its a bug in the hardware and the 
hardwares spec it be quite hard to fix by a compiler.
Dec 14
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Not following the IEEE 754 spec to the letter means "D has a broken floating 
point implementation." That's not going to happen. People write very carefully 
crafted floating point code relying on exact adherence to the spec.
Dec 14
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 14 December 2025 at 20:36:42 UTC, Walter Bright wrote:

 Not following the IEEE 754 spec to the letter means "D has a 
 broken floating point implementation." That's not going to 
 happen. People write very carefully crafted floating point code 
 relying on exact adherence to the spec.


And? Specs are just words written by mere mortals, it be a trade 
off with upsides to ignore them. It be nice if the 2nd most 
important type at least had some level of consistency with the 
1st.

I understand some airplane surgery theory tells ya to want 
float.init to be nan; I just see a pile of complexity for trying 
to meta program, Im aware of like 3 things that make the 
landscape of d's type theory hard, ieee floats + your thoerys are 
an as an unforced error as autodecoding is.

Floats being number-y and kinda nullable-y, means my goals of 
extremely strong api's gets to consider how to combine nullables 
with bools instead of nullables being a simply a container and 
segmented completely elsewhere. But nah, we get to merge it all 
together in a big ball of complexity.
Dec 14
parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 14 December 2025 at 21:01:20 UTC, monkyyy wrote:

 I understand some airplane surgery theory tells ya to want 
 float.init to be nan; I just see a pile of complexity for 
 trying to meta program, Im aware of like 3 things that make the 
 landscape of d's type theory hard, ieee floats + your thoerys 
 are an as an unforced error as autodecoding is.

 Floats being number-y and kinda nullable-y, means my goals of 
 extremely strong api's gets to consider how to combine 
 nullables with bools instead of nullables being a simply a 
 container and segmented completely elsewhere. But nah, we get 
 to merge it all together in a big ball of complexity.


Floats should not work differently based on language. At least 
not for low level ones. Like should `0.0 == 0.1 + 0.2 - 0.3` be 
true too? The float.init thing is debatable, ok ok.

Anyway, what was the topic again of this forum post?
Dec 14
parent monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 14 December 2025 at 21:18:48 UTC, Kapendev wrote:

 
 Anyway, what was the topic again of this forum post?


Probably sometin to do with making a browser checker
Dec 14
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/25 21:36, Walter Bright wrote:

 Not following the IEEE 754 spec to the letter means "D has a broken 
 floating point implementation."


To be fair, D does have a broken floating point implementation.


 That's not going to happen. People write 
 very carefully crafted floating point code relying on exact adherence to 
 the spec.


Which then by the D spec does not matter because D is actually allowed 
to randomly use the wrong floating point types and introduce additional 
conversions and rounding imprecision.

Here's another recent complaint:
https://forum.dlang.org/thread/hvftxmrqvrmficcvlkqi forum.dlang.org
Dec 14
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 8:02 PM, Timon Gehr wrote:

 To be fair, D does have a broken floating point implementation.


Only insofar as the x87's implementation.



 Which then by the D spec does not matter because D is actually allowed to 
 randomly use the wrong floating point types and introduce additional
conversions 
 and rounding imprecision.


This was fixed a few years ago, excepting that we do what everyone else does 
with the x87.



 Here's another recent complaint:
 https://forum.dlang.org/thread/hvftxmrqvrmficcvlkqi forum.dlang.org


Different compilers have different long double sizes.

None of that has anything to do with NaN behavior.
Dec 17
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/18/25 06:04, Walter Bright wrote:

 On 12/14/2025 8:02 PM, Timon Gehr wrote:

 To be fair, D does have a broken floating point implementation.


 
 Only insofar as the x87's implementation.
 ...


https://dlang.org/spec/float.html


 

 Which then by the D spec does not matter because D is actually allowed 
 to randomly use the wrong floating point types and introduce 
 additional conversions and rounding imprecision.


 
 This was fixed a few years ago,


https://dlang.org/spec/float.html


 excepting that we do what everyone else does with the x87.
 ...


This can't really be true, because there is not even a single x87 
behavior that is used.
https://github.com/dlang/dmd/issues/20339

We might or might not use the x87 even when there is no `real` involved 
anywhere and we are working strictly with `float` or `double` data. 
Neither `float` nor `double` arithmetic is even supported by the x87 
unless you configure it to not do double rounding, and you have to write 
back to memory after every operation to catch out-of-range exponents. 
(Afaiu none of the D implementations do any of this.)
https://dlang.org/spec/float.html


 

 Here's another recent complaint:
 https://forum.dlang.org/thread/hvftxmrqvrmficcvlkqi forum.dlang.org


 
 Different compilers have different long double sizes.
 ...


Not the problem, D does not have "long double", and we do not even have 
to use `real` to get the broken behavior. If you read that thread, 
obviously equivalent D code that executes the same float operations on 
the same declared types (`double`!) in the same order works correctly 
only when the optimizer happens to feel like it. (This is comparing D 
code to D code, no "long double" or `real` or any other 
implementation-defined floating-point storage type involved.)


 None of that has anything to do with NaN behavior.


The justification of not wanting to have a broken floating point 
implementation applies in all of these cases.

Anyway, this is on topic, because changing e.g., constant folding to 
work correctly can be a breaking change.
Dec 18
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 5:27 AM, Dom Disc wrote:

 IEEE754 compliance is both expected and baked into the CPU hardware.


 
 Yup. But it only requires NaN == 0 to be false. It doesn't talk about NaN != 0 
 at all.


Googling NaN and IEEE754 will produce an explanation of this, since you don't 
believe me :-) The explanation is NaN is never equal to anything, so NaN!=0 is
true.

I implemented NaN behavior in the 1980s, and was very scrupulous in doing it 
exactly according to the spec, regardless of what I thought would be better. If 
I had done it differently, I would have been subject to endless complaints.
Dec 14
prev sibling next sibling parent reply Sadiel <bruh lol.us> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.

 I'll start by eliminating -revert=intpromote


I think this is the way, focusing first on eliminating things 
instead of adding more.

This is a list of things that the D team have wanted to remove 
over the years:

- Complex number support
- Lazy attribute
- Some problematic features of classes, __traits(compiles, ...)
- alias this
- Extern C++ with an identifier for the namespace

Now, what I would like is to simplify the syntax:
There are like 5 ways of creating delegates, wouldn't be better 
to stick to one?
Make different keywords instead of overusing them, for example 
static.

For completeness this are things that the D team have wanted to 
add or change over the years:
- Constructor syntax
- Pattern Matching
- Import C++

Sources:
https://www.youtube.com/watch?v=vb45QflK7Mk&t=29893s
https://www.youtube.com/watch?v=cUkUZmkYsiY&list=PLIldXzSkPUXWH97DYBENhAqLk4DUqKUmf&index=21&t=1913s
https://www.youtube.com/watch?v=rcyQdntgzQM&list=PLIldXzSkPUXVDzfnBlXcqZF6GB_ejjkEn&index=7&t=1530s
Dec 13
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 13 December 2025 at 21:25:29 UTC, Sadiel wrote:

 This is a list of things that the D team have wanted to remove 
 over the years:

 - Complex number support


As it's already deprecated, should be OK to error on this in an 
edition.


 - Lazy attribute





 - Some problematic features of classes,


Do you mean something like ProtoObject?


 __traits(compiles, ...)


Can you expand on that?


 - alias this


For classes, maybe it would be sufficient to:
1. Forbid alias this from producing anything that implicitly 
converts to Object.
2. Forbid alias this if a superclass has already defined it.

For structs, I think there was some plan to replace it, but I 
never saw details.


 - Extern C++ with an identifier for the namespace

 Now, what I would like is to simplify the syntax:
 There are like 5 ways of creating delegates, wouldn't be better 
 to stick to one?


It might be justified to remove BlockStatement from 
[FunctionLiteral](https://dlang.org/spec/expression.html#function_literals), to
make parsing easier. Use `() { ... }` instead.


 Make different keywords instead of overusing them, for example 
 static.


I think that would need to demonstrate that overloading static 
has a cost for people once they've learnt the language, or that 
learning the meanings is a significant obstacle. There's the cost 
of new keywords breaking existing code, unless they start with 
`__`. Also learners may get confused about 2 forms of syntax as 
long as the `static` syntax variant is supported.

IMO we should use editions to fix bug-prone features, reduce 
unnecessary complexity or fix badly implemented features. I think 
there should be a reasonable limit to the amount of breakage when 
upgrading editions, prioritized by need. Just redesigning syntax 
needs quite a high bar to justify it.


 For completeness this are things that the D team have wanted to 
 add or change over the years:
 - Constructor syntax


Recently there has been discussion of explicit this parameters, 
but I don't know that removal of current syntax would happen. 
Additions can happen without an edition.


 - Pattern Matching
 - Import C++
Dec 15
parent reply Lance Bachmeier <no spam.net> writes:
On Monday, 15 December 2025 at 12:26:04 UTC, Nick Treleaven wrote:

 On Saturday, 13 December 2025 at 21:25:29 UTC, Sadiel wrote:

 - alias this


 For classes, maybe it would be sufficient to:
 1. Forbid alias this from producing anything that implicitly 
 converts to Object.
 2. Forbid alias this if a superclass has already defined it.

 For structs, I think there was some plan to replace it, but I 
 never saw details.


Walter has indicated a desire to not use editions as an excuse to 
ruin the language.

alias this with structs is very useful. There is no reason to 
remove it or make it unusable just because a few people think it 
can be dangerous. One might also argue that pointers are 
dangerous, but that's not an argument for removing them. Removal 
of alias this would make the language unusable for me.
Dec 15
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 15 December 2025 at 16:59:07 UTC, Lance Bachmeier 
wrote:

 On Monday, 15 December 2025 at 12:26:04 UTC, Nick Treleaven 
 wrote:

 On Saturday, 13 December 2025 at 21:25:29 UTC, Sadiel wrote:

 - alias this


 For classes, maybe it would be sufficient to:
 1. Forbid alias this from producing anything that implicitly 
 converts to Object.
 2. Forbid alias this if a superclass has already defined it.

 For structs, I think there was some plan to replace it, but I 
 never saw details.


 Walter has indicated a desire to not use editions as an excuse 
 to ruin the language.

 alias this with structs is very useful. There is no reason to 
 remove it or make it unusable just because a few people think 
 it can be dangerous. One might also argue that pointers are 
 dangerous, but that's not an argument for removing them. 
 Removal of alias this would make the language unusable for me.


Thats optimistic, editions will reopen any ongoing compromise 
that happened due to "backwards compatibility", get ready to 
reargue for any such positions
Dec 15
parent reply Lance Bachmeier <no spam.net> writes:
On Monday, 15 December 2025 at 17:45:22 UTC, monkyyy wrote:


 Thats optimistic, editions will reopen any ongoing compromise 
 that happened due to "backwards compatibility", get ready to 
 reargue for any such positions


Don't worry. I won't argue because that would be a waste of my 
time.
Dec 15
parent monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 15 December 2025 at 17:51:32 UTC, Lance Bachmeier 
wrote:

 On Monday, 15 December 2025 at 17:45:22 UTC, monkyyy wrote:


 Thats optimistic, editions will reopen any ongoing compromise 
 that happened due to "backwards compatibility", get ready to 
 reargue for any such positions


 Don't worry. I won't argue because that would be a waste of my 
 time.


?

You dont get what you dont ask for. You have to cast at least a 
single perl in front of walter.
Dec 15
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 15 December 2025 at 16:59:07 UTC, Lance Bachmeier 
wrote:

 On Monday, 15 December 2025 at 12:26:04 UTC, Nick Treleaven 
 wrote:

 For structs, I think there was some plan to replace it, but I 
 never saw details.


 Walter has indicated a desire to not use editions as an excuse 
 to ruin the language.

 alias this with structs is very useful. There is no reason to 
 remove it or make it unusable just because a few people think 
 it can be dangerous. One might also argue that pointers are 
 dangerous, but that's not an argument for removing them. 
 Removal of alias this would make the language unusable for me.


I don't know if there is a plan now to replace it, I'd guess not. 
I am not aware of any reason why `alias this` should be removed 
(for structs at least). If there was a replacement feature, it 
should be capable of everything `alias this` can currently do 
IMO, so that there would be an upgrade path.

There was a project item to 'Explore a replacement for alias 
this':
https://github.com/orgs/dlang/projects/22/views/1?pane=issue&itemId=29572699

Though that was part of a set which was closed (maybe last year).
Dec 16
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 17/12/2025 9:35 AM, Nick Treleaven wrote:

 On Monday, 15 December 2025 at 16:59:07 UTC, Lance Bachmeier wrote:

 On Monday, 15 December 2025 at 12:26:04 UTC, Nick Treleaven wrote:

 For structs, I think there was some plan to replace it, but I never 
 saw details.


 Walter has indicated a desire to not use editions as an excuse to ruin 
 the language.

 alias this with structs is very useful. There is no reason to remove 
 it or make it unusable just because a few people think it can be 
 dangerous. One might also argue that pointers are dangerous, but 
 that's not an argument for removing them. Removal of alias this would 
 make the language unusable for me.


 
 I don't know if there is a plan now to replace it, I'd guess not. I am 
 not aware of any reason why `alias this` should be removed (for structs 
 at least). If there was a replacement feature, it should be capable of 
 everything `alias this` can currently do IMO, so that there would be an 
 upgrade path.
 
 There was a project item to 'Explore a replacement for alias this':
 https://github.com/orgs/dlang/projects/22/views/1? 
 pane=issue&itemId=29572699
 
 Though that was part of a set which was closed (maybe last year).


I have my own plans, but they'll need to be discussed next month.

https://forum.dlang.org/post/llqcjziyurwmyhzseonm forum.dlang.org

We don't need alias this semantic, but we do need a fallback lookup via 
a method.

Get rid of the overriding capability, and let things stay single 
inheritance.
Dec 16
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 16 December 2025 at 20:45:21 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 [snip]

 I have my own plans, but they'll need to be discussed next 
 month.

 https://forum.dlang.org/post/llqcjziyurwmyhzseonm forum.dlang.org

 We don't need alias this semantic, but we do need a fallback 
 lookup via a method.

 Get rid of the overriding capability, and let things stay 
 single inheritance.


As was said above, I think people would have an open mind so long 
as there is an upgrade path. I think a lot of people would have 
trouble with removing "alias this" without one.
Dec 16
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 17/12/2025 10:02 AM, jmh530 wrote:

 On Tuesday, 16 December 2025 at 20:45:21 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 [snip]

 I have my own plans, but they'll need to be discussed next month.

 https://forum.dlang.org/post/llqcjziyurwmyhzseonm forum.dlang.org

 We don't need alias this semantic, but we do need a fallback lookup 
 via a method.

 Get rid of the overriding capability, and let things stay single 
 inheritance.


 
 As was said above, I think people would have an open mind so long as 
 there is an upgrade path. I think a lot of people would have trouble 
 with removing "alias this" without one.


Yeah absolutely.

But there will be some behavior that won't be replicated wrt. 
overriding, and that is an intentional breakage.

For instance I don't want fields supported, just a single method.
You don't need fields supported.

```d
T field;

ref T opDispatch(string op : "") => field;
```

Longer sure, (and yes there are opinions about a different signature), 
but it'll optimize out and keeps it being a simpler feature.

I'm sure once discussed it'll change, I would be surprised if it 
survives a meeting for what I came up with.
Dec 16
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/16/25 21:45, Richard (Rikki) Andrew Cattermole wrote:

 
 On 17/12/2025 9:35 AM, Nick Treleaven wrote:

 On Monday, 15 December 2025 at 16:59:07 UTC, Lance Bachmeier wrote:

 On Monday, 15 December 2025 at 12:26:04 UTC, Nick Treleaven wrote:

 For structs, I think there was some plan to replace it, but I never 
 saw details.


 Walter has indicated a desire to not use editions as an excuse to 
 ruin the language.

 alias this with structs is very useful. There is no reason to remove 
 it or make it unusable just because a few people think it can be 
 dangerous. One might also argue that pointers are dangerous, but 
 that's not an argument for removing them. Removal of alias this would 
 make the language unusable for me.


 I don't know if there is a plan now to replace it, I'd guess not. I am 
 not aware of any reason why `alias this` should be removed (for 
 structs at least). If there was a replacement feature, it should be 
 capable of everything `alias this` can currently do IMO, so that there 
 would be an upgrade path.

 There was a project item to 'Explore a replacement for alias this':
 https://github.com/orgs/dlang/projects/22/views/1? 
 pane=issue&itemId=29572699

 Though that was part of a set which was closed (maybe last year).


 
 I have my own plans, but they'll need to be discussed next month.
 
 https://forum.dlang.org/post/llqcjziyurwmyhzseonm forum.dlang.org
 
 We don't need alias this semantic, but we do need a fallback lookup via 
 a method.
 
 Get rid of the overriding capability, and let things stay single 
 inheritance.


D also allows multiple module imports, just use the same lookup rules 
and disambiguation strategies.

It's a solved problem. The reason why we were not able to do this is 
that it breaks code that relies on the ad-hoc mess that has grown over 
the years instead. There is no need to go overboard and delete the whole 
concept now that we got editions that allow us to solve the problem in 
the obvious way.

Of course, we can also use different syntax. Forwarding to members is 
useful without implicit conversion and even vice-versa.
Dec 16
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 17/12/2025 11:43 AM, Timon Gehr wrote:

 On 12/16/25 21:45, Richard (Rikki) Andrew Cattermole wrote:

 On 17/12/2025 9:35 AM, Nick Treleaven wrote:

 On Monday, 15 December 2025 at 16:59:07 UTC, Lance Bachmeier wrote:

 On Monday, 15 December 2025 at 12:26:04 UTC, Nick Treleaven wrote:

 For structs, I think there was some plan to replace it, but I never 
 saw details.


 Walter has indicated a desire to not use editions as an excuse to 
 ruin the language.

 alias this with structs is very useful. There is no reason to remove 
 it or make it unusable just because a few people think it can be 
 dangerous. One might also argue that pointers are dangerous, but 
 that's not an argument for removing them. Removal of alias this 
 would make the language unusable for me.


 I don't know if there is a plan now to replace it, I'd guess not. I 
 am not aware of any reason why `alias this` should be removed (for 
 structs at least). If there was a replacement feature, it should be 
 capable of everything `alias this` can currently do IMO, so that 
 there would be an upgrade path.

 There was a project item to 'Explore a replacement for alias this':
 https://github.com/orgs/dlang/projects/22/views/1? 
 pane=issue&itemId=29572699

 Though that was part of a set which was closed (maybe last year).


 I have my own plans, but they'll need to be discussed next month.

 https://forum.dlang.org/post/llqcjziyurwmyhzseonm forum.dlang.org

 We don't need alias this semantic, but we do need a fallback lookup 
 via a method.

 Get rid of the overriding capability, and let things stay single 
 inheritance.


 
 D also allows multiple module imports, just use the same lookup rules 
 and disambiguation strategies.
 
 It's a solved problem. The reason why we were not able to do this is 
 that it breaks code that relies on the ad-hoc mess that has grown over 
 the years instead. There is no need to go overboard and delete the whole 
 concept now that we got editions that allow us to solve the problem in 
 the obvious way.
 
 Of course, we can also use different syntax. Forwarding to members is 
 useful without implicit conversion and even vice-versa.


Yeah it'll work.

My preference is to keep it simple and disambiguate from the old 
behavior but otherwise it archives the same goal.
Dec 16
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 16, 2025 1:35:18 PM Mountain Standard Time Nick
Treleaven via Digitalmars-d wrote:

 On Monday, 15 December 2025 at 16:59:07 UTC, Lance Bachmeier
 wrote:

 On Monday, 15 December 2025 at 12:26:04 UTC, Nick Treleaven
 wrote:

 For structs, I think there was some plan to replace it, but I
 never saw details.


 Walter has indicated a desire to not use editions as an excuse
 to ruin the language.

 alias this with structs is very useful. There is no reason to
 remove it or make it unusable just because a few people think
 it can be dangerous. One might also argue that pointers are
 dangerous, but that's not an argument for removing them.
 Removal of alias this would make the language unusable for me.


 I don't know if there is a plan now to replace it, I'd guess not.
 I am not aware of any reason why `alias this` should be removed
 (for structs at least). If there was a replacement feature, it
 should be capable of everything `alias this` can currently do
 IMO, so that there would be an upgrade path.

 There was a project item to 'Explore a replacement for alias
 this':
 https://github.com/orgs/dlang/projects/22/views/1?pane=issue&itemId=29572699

 Though that was part of a set which was closed (maybe last year).


At dconf in 2024, it was discussed that we would ideally get rid of alias
this but that we weren't going to, because it would break existing code. As
a replacement, Walter's proposal was to add struct inheritance so that you'd
do something like

struct S : Base
{
}

and all of the members of Base would effectively be copy-pasted into S. That
way, a struct could inherit the members of another struct, but there would
be no implicit conversion that resulted, because S wouldn't be a Base (like
occurs with class inheritance). It would just be copying the implementation.
That way, it's possible to reuse code without having all of the problems
that the implicit conversion that alias this introduces causes.

However, AFAIK, Walter hasn't actually done anything with that idea yet, and
there isn't a DIP for it yet.

It's possible that once such struct inheritance is in the language that we'd
then get rid of alias this in a future Edition, but no such decision has
been made. And regardless of what happens with that in the future, I don't
think that there's any chance that alias this would be removed in the first
Edition. The struct inheritance stuff needs to be sorted out first.

- Jonathan M Davis
Dec 17
prev sibling next sibling parent reply Ogion <ogion.art gmail.com> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.


Non-ASCII characters in identifiers. This is a “feature” that has 
no value but creates the more headaches the more it’s used.
Dec 13
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/12/2025 12:16 PM, Ogion wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, and 
 Rikki) it's time to solicit D features to be dropped from the next 
 Edition of D.


 
 Non-ASCII characters in identifiers. This is a “feature” that has no 
 value but creates the more headaches the more it’s used.


We have non-english speaking users that require UAX31 support.

I spent a fair bit of time implementing UAX31, this can't go away.
Dec 13
parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 13 December 2025 at 23:23:23 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 14/12/2025 12:16 PM, Ogion wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright 
 wrote:

 Now that Editions have been implemented (thanks Atila, 
 Dennis, and Rikki) it's time to solicit D features to be 
 dropped from the next Edition of D.


 
 Non-ASCII characters in identifiers. This is a “feature” that 
 has no value but creates the more headaches the more it’s used.


 We have non-english speaking users that require UAX31 support.

 I spent a fair bit of time implementing UAX31, this can't go 
 away.


Also it's required for compatibility with newer C and C++ 
standards.

"I spent a bunch of time implementing this" is not a good 
argument in favor of keeping a feature. Sunk costs are sunk costs.
Dec 13
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/12/2025 4:15 PM, Paul Backus wrote:

 On Saturday, 13 December 2025 at 23:23:23 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 14/12/2025 12:16 PM, Ogion wrote:

 On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, and 
 Rikki) it's time to solicit D features to be dropped from the next 
 Edition of D.


 Non-ASCII characters in identifiers. This is a “feature” that has no 
 value but creates the more headaches the more it’s used.


 We have non-english speaking users that require UAX31 support.

 I spent a fair bit of time implementing UAX31, this can't go away.


 
 Also it's required for compatibility with newer C and C++ standards.
 
 "I spent a bunch of time implementing this" is not a good argument in 
 favor of keeping a feature. Sunk costs are sunk costs.


No it isn't, and in this case, the work put in directly correlates to 
how important I view it.
Dec 13
prev sibling next sibling parent reply Clouudy <Swergers123 gmail.com> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.

 I'll start by eliminating -revert=intpromote


Auto-removing `immutable` when working with C bindings would be 
helpful, particularly for strings. Something like that at least, 
I'm not sure that actually removing `immutable` would be a good 
idea.
Dec 14
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2025 1:49 PM, Clouudy wrote:

 Auto-removing `immutable` when working with C bindings would be helpful, 
 particularly for strings. Something like that at least, I'm not sure that 
 actually removing `immutable` would be a good idea.


C semantics are not thread-safe, and immutables are thread-safe.
Dec 17
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.


  - Pretty much what is deprecated right now.

  - Maybe C-style alias declarations. The parser will still have 
to recognise them as it can't know which edition the file has but 
still.

  - ` system` by default, if you can come to an agreement in the 
foundation meetings what scheme will follow.

  - ` safe` external functions that don't have a D linkage (they 
would have to be designated ` trusted` instead).

  - All `finally` blocks, and by extension `scope(failure)` and 
destructors running when catching non-`Exception` Throwables. The 
problem is that if a `nothrow` functions throws one, the finally 
block might or might not run. If non-exception throwables would 
be intercepted only with an explicit catch block for one, there 
would be no implementation defined behaviour yet we still could 
have the `nothrow`-based optimisations.
Dec 15
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 16/12/2025 10:30 AM, Dukc wrote:

 All |finally| blocks, and by extension |scope(failure)| and destructors 
 running when catching non-|Exception| Throwables. The problem is that if 
 a |nothrow| functions throws one, the finally block might or might not 
 run. If non-exception throwables would be intercepted only with an 
 explicit catch block for one, there would be no implementation defined 
 behaviour yet we still could have the |nothrow|-based optimisations.


Fixed.

https://github.com/dlang/dmd/blob/master/changelog/dmd.exception-rewrite.dd

Also you may be interested in: 
https://github.com/dlang/dmd/blob/master/changelog/druntime.filterthrown.dd
Dec 15
parent Dukc <ajieskola gmail.com> writes:
On Monday, 15 December 2025 at 21:33:34 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 Fixed.

 https://github.com/dlang/dmd/blob/master/changelog/dmd.exception-rewrite.dd


Thanks!


 Also you may be interested in: 
 https://github.com/dlang/dmd/blob/master/changelog/druntime.filterthrown.dd


Same name as in my suggestion at some forum post like maybe two 
years ago to a problem in multithreaded error handling. I have to 
check, out of interest, how closely this matches my proposal.
Dec 15
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 15 December 2025 at 21:30:18 UTC, Dukc wrote:

  - Maybe C-style alias declarations. The parser will still have 
 to recognise them as it can't know which edition the file has 
 but still.


https://github.com/dlang/dmd/pull/22244

The parser can tell when it is specified in the file. The 
compiler should set the `Module.edition` field before the parser 
receives the `Module` instance when a matching `-edition` or `-E` 
flag is passed. AFAICT `-edition` seems to be supported but 
ignored currently in recent git dmd, and `-E` isn't implemented. 
I'll file a bug.

...

  - ` safe` external functions that don't have a D linkage (they 
 would have to be designated ` trusted` instead).


+1
Dec 16
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 17/12/2025 9:11 AM, Nick Treleaven wrote:

 On Monday, 15 December 2025 at 21:30:18 UTC, Dukc wrote:

  - Maybe C-style alias declarations. The parser will still have to 
 recognise them as it can't know which edition the file has but still.


 
 https://github.com/dlang/dmd/pull/22244
 
 The parser can tell when it is specified in the file. The compiler 
 should set the `Module.edition` field before the parser receives the 
 `Module` instance when a matching `-edition` or `-E` flag is passed. 
 AFAICT `-edition` seems to be supported but ignored currently in recent 
 git dmd, and `-E` isn't implemented. I'll file a bug.
 
 ...

  - ` safe` external functions that don't have a D linkage (they would 
 have to be designated ` trusted` instead).


 
 +1
 


It is implemented. Walter did it.

https://github.com/dlang/dmd/blob/063ee15f6fa93c270f475bffd646b58e61e1294d/compiler/src/dmd/cli.d#L353

https://github.com/dlang/dmd/blob/063ee15f6fa93c270f475bffd646b58e61e1294d/compiler/src/dmd/mars.d#L897

As far as I'm aware editions is fully implemented.
Dec 16
parent Nick Treleaven <nick geany.org> writes:
On Tuesday, 16 December 2025 at 20:43:21 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 17/12/2025 9:11 AM, Nick Treleaven wrote:

 The parser can tell when it is specified in the file. The 
 compiler should set the `Module.edition` field before the 
 parser receives the `Module` instance when a matching 
 `-edition` or `-E` flag is passed. AFAICT `-edition` seems to 
 be supported but ignored currently in recent git dmd, and `-E` 
 isn't implemented. I'll file a bug.


 It is implemented. Walter did it.

 https://github.com/dlang/dmd/blob/063ee15f6fa93c270f475bffd646b58e61e1294d/compiler/src/dmd/cli.d#L353

 https://github.com/dlang/dmd/blob/063ee15f6fa93c270f475bffd646b58e61e1294d/compiler/src/dmd/mars.d#L897

 As far as I'm aware editions is fully implemented.


No, `params.edition` is set but never read. Fix: 
https://github.com/dlang/dmd/pull/22248
Dec 17
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 12 December 2025 at 23:05:27 UTC, Walter Bright wrote:

 Now that Editions have been implemented (thanks Atila, Dennis, 
 and Rikki) it's time to solicit D features to be dropped from 
 the next Edition of D.

 I'll start by eliminating -revert=intpromote


This may not be something worth pursuing for the first edition, 
given the ideas thrown around already, but I was reading about 
Odin's context system [1, 2] and found it interesting.

The idea is that functions include "a pointer to the current 
context as an implicit additional argument.". It looks to be 
helpful with managing allocators.

Obviously, if you just move straight to this, you could break a 
lot of code. But you could introduce an `extern(D-context)` so 
that people could opt-in to this implicit context approach.

Or maybe there's an even better way to do this that makes the 
most sense for D. It at least seems better than writing 
`theAllocator` everywhere. And if could get incorporated into how 
the GC is called, then maybe that would be a win too.


[1] https://odin-lang.org/docs/overview/
[2] 
https://www.gingerbill.org/article/2025/12/15/odins-most-misunderstood-feature-context/
Dec 16
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/16/2025 1:12 PM, jmh530 wrote:

 The idea is that functions include "a pointer to the current context as an 
 implicit additional argument.". It looks to be helpful with managing
allocators.


That sounds like member functions?
Dec 17
next sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Thursday, 18 December 2025 at 05:57:35 UTC, Walter Bright 
wrote:

 On 12/16/2025 1:12 PM, jmh530 wrote:

 The idea is that functions include "a pointer to the current 
 context as an implicit additional argument.". It looks to be 
 helpful with managing allocators.


 That sounds like member functions?


Yes, kinda, but it's copy-on-write.
One issue with that system is handling static constructors, plus 
dealing with an extra calling convention.
Dec 17
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 18/12/2025 7:32 PM, Kapendev wrote:

 On Thursday, 18 December 2025 at 05:57:35 UTC, Walter Bright wrote:

 On 12/16/2025 1:12 PM, jmh530 wrote:

 The idea is that functions include "a pointer to the current context 
 as an implicit additional argument.". It looks to be helpful with 
 managing allocators.


 That sounds like member functions?


 
 Yes, kinda, but it's copy-on-write.
 One issue with that system is handling static constructors, plus dealing 
 with an extra calling convention.


There is a fairly straight forward way to do this, without adding 
specific library into the language.

To borrow an idea for Swift, use a TLS variable as the bottom of the stack.

```d
Something* something;

void userFunc() {
	// Something __temp = Something(something);
	// something = &__temp;
	// scope(exit) something = __temp.parent;

	something.cool(); // actually __temp.cool();
}
```

Implicit temporaries for globals.
Dec 17
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 18 December 2025 at 05:57:35 UTC, Walter Bright 
wrote:

 On 12/16/2025 1:12 PM, jmh530 wrote:

 The idea is that functions include "a pointer to the current 
 context as an implicit additional argument.". It looks to be 
 helpful with managing allocators.


 That sounds like member functions?


The implicit aspect of it is similar, but not exactly the same 
since the context depends on the scope and can be overridden.

It's described in more detail here [1], which I reproduce below 
and then it follows with a discussion of how it applies to 
allocators [2] (which I'm going not going to include)

---

In each scope, there is an implicit value named context. This 
context variable is local to each scope and is implicitly passed 
by pointer to any procedure call in that scope (if the procedure 
has the Odin calling convention).

The main purpose of the implicit context system is for the 
ability to intercept third-party code and libraries and modify 
their functionality. One such case is modifying how a library 
allocates something or logs something. In C, this was usually 
achieved with the library defining macros which could be 
overridden so that the user could define what they wanted. 
However, not many libraries supported this in many languages by 
default which meant intercepting third-party code to see what it 
does and to change how it does it was not possible.

```
main :: proc() {
	c := context // copy the current scope's context

	context.user_index = 456
	{
		context.allocator = my_custom_allocator()
		context.user_index = 123
		supertramp() // the `context` for this scope is implicitly 
passed to `supertramp`
	}

	// `context` value is local to the scope it is in
	assert(context.user_index == 456)
}

supertramp :: proc() {
	c := context // this `context` is the same as the parent 
procedure that it was called from
	// From this example, context.user_index == 123
	// A context.allocator is assigned to the return value of 
`my_custom_allocator()`

	// The memory management procedure uses the `context.allocator` 
by default unless explicitly specified otherwise
	ptr := new(int)
	free(ptr)
}
```

By default, the context value has default values for its 
parameters which is decided in the package runtime. These 
defaults are compiler specific.

To see what the implicit context value contains, please see the 
definition of the Context struct in package runtime.


[1] https://odin-lang.org/docs/overview/#implicit-context-system
[2] https://odin-lang.org/docs/overview/#allocators
Dec 18
prev sibling parent reply Richard (Rikki) Andrew Cattermole <richard cattermole.co.nz> writes:
Here is my initial list, it will likely change between now and 
next month.

I was going to produce this earlier to get people on the right 
idea, but alas this needed writing up in a way that isn't just a 
cue card to myself!

I want to note, that the first edition is mostly focused on 
breakage not new features.

- We have both throw expressions and throw statements. We do not 
need throw statements if we have throw expressions.
- Case statements should only accept expressions that resolve to 
a value, not variables: https://github.com/dlang/dmd/pull/14829
- Disallow symbols being called ``init``. Being able to do this 
breaks code.
- Disallow catching anything other than Exception hierarchy (no 
Error/Throwable) unless try statement is whitelisted with pragma
	- Being able to catch Throwable/Error should be left to code 
like schedulers it is not normal  system code that needs this and 
outside of these use cases it should never be done.
- Class constructor inheritance when none are provided
	- Does not count constructors of the form: this(params...) => 
super(stuff here)
	- Derived from Swift, without adding new special variants.
- Remove the ability to cast a class to ``void*`` to get at its 
instance pointer.
	- Add ``.instanceptr`` property instead.
	- The cast is broken if you add an ``opCast``, which practically 
means that you should pretty much never use it.
- Turn on -preview=fixaliasthis
- Turn on: rvaluerefparam
	- Known bugs:
		- https://github.com/dlang/dmd/issues/22078
- Turn on: nosharedaccess
	- Known bugs:
		- https://github.com/dlang/dmd/issues/20496
- Turn on fixImmutableConv
	- Known bugs:
		- https://github.com/dlang/dmd/issues/18246
		- https://github.com/dlang/dmd/issues/20401 (forestix, not 
original code)
		- https://github.com/dlang/dmd/issues/19910
- Turn on systemVariables
	- Known bugs:
		- https://github.com/dlang/dmd/issues/18195
- Turn on inclusiveincontracts
	- Known bugs:
		- https://github.com/dlang/dmd/issues/17646
- Turn on fieldwise
- Turn on bitfields
Dec 17
parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 17 December 2025 at 16:07:26 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 Here is my initial list, it will likely change between now and 
 next month.


It's a very good list! A few things stuck out:


 - We have both throw expressions and throw statements. We do 
 not need throw statements if we have throw expressions.


How does this break code? It looks to me like we could refactor 
the implementation without anyone noticing.


 - Class constructor inheritance when none are provided
 	- Does not count constructors of the form: this(params...) => 
 super(stuff here)
 	- Derived from Swift, without adding new special variants.
 - Remove the ability to cast a class to ``void*`` to get at its
 instance pointer.
 	- Add ``.instanceptr`` property instead.


Are there issues for this on GitHub?


 - Turn on bitfields


This is already turned on, no edition needed.

https://github.com/dlang/dmd/pull/21625
Dec 18
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 19/12/2025 4:03 AM, Dennis wrote:

 On Wednesday, 17 December 2025 at 16:07:26 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 Here is my initial list, it will likely change between now and next 
 month.


 
 It's a very good list! A few things stuck out:
 

 - We have both throw expressions and throw statements. We do not need 
 throw statements if we have throw expressions.


 
 How does this break code? It looks to me like we could refactor the 
 implementation without anyone noticing.


I don't know, I've kinda assumed that there was a reason it hasn't been 
done beyond somebody not doing it.


 - Class constructor inheritance when none are provided
     - Does not count constructors of the form: this(params...) => 
 super(stuff here)
     - Derived from Swift, without adding new special variants.
 - Remove the ability to cast a class to ``void*`` to get at its
 instance pointer.
     - Add ``.instanceptr`` property instead.


 
 Are there issues for this on GitHub?


Apparently not.

https://github.com/dlang/dmd/issues/22260
Dec 18