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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
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 2025
prev sibling next 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 2025
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 15 December 2025 at 04:20:21 UTC, Mike Shah wrote:

 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.


I don't think anyone should be using features like ` live` 
themselves and instead the language should provide the features 
that allow one to write library solutions like smart pointers.
Jan 05
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/01/2026 11:20 PM, Atila Neves wrote:

 On Monday, 15 December 2025 at 04:20:21 UTC, Mike Shah wrote:

 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.


 
 I don't think anyone should be using features like ` live` themselves 
 and instead the language should provide the features that allow one to 
 write library solutions like smart pointers.


 live goes on user functions, it has nothing to do with smart pointers 
or library code.
Jan 05
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 1/5/26 12:29, Richard (Rikki) Andrew Cattermole wrote:


 I don't think anyone should be using features like ` live` themselves 
 and instead the language should provide the features that allow one to 
 write library solutions like smart pointers.


 
  live goes on user functions, it has nothing to do with smart pointers 
 or library code.


Which is precisely why it is of such mindbogglingly limited utility.



 Jan 05



prev sibling  parent reply Atila Neves <atila.neves gmail.com>  writes:


On Monday, 5 January 2026 at 11:29:19 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 05/01/2026 11:20 PM, Atila Neves wrote:

 On Monday, 15 December 2025 at 04:20:21 UTC, Mike Shah wrote:

 On Sunday, 14 December 2025 at 20:16:34 UTC, Walter Bright 
 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.


 
 I don't think anyone should be using features like ` live` 
 themselves and instead the language should provide the 
 features that allow one to write library solutions like smart 
 pointers.


  live goes on user functions, it has nothing to do with smart 
 pointers or library code.


Yes, and I'm saying that users shouldn't be allocating with 
malloc/free.



 Jan 16



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 17/01/2026 4:21 AM, Atila Neves wrote:

 On Monday, 5 January 2026 at 11:29:19 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 05/01/2026 11:20 PM, Atila Neves wrote:

 On Monday, 15 December 2025 at 04:20:21 UTC, Mike Shah wrote:

 On Sunday, 14 December 2025 at 20:16:34 UTC, Walter Bright 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.


 I don't think anyone should be using features like ` live` themselves 
 and instead the language should provide the features that allow one 
 to write library solutions like smart pointers.


  live goes on user functions, it has nothing to do with smart pointers 
 or library code.


 
 Yes, and I'm saying that users shouldn't be allocating with malloc/free.


I agree, but such library types have nothing to do with  live.

So I don't understand why you have introduced it here in this thread.



 Jan 16



prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com>  writes:


On Monday, 5 January 2026 at 10:20:50 UTC, Atila Neves wrote:

 [snip]

  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.


 I don't think anyone should be using features like ` live` 
 themselves and instead the language should provide the features 
 that allow one to write library solutions like smart pointers.


Anyone? Someone has the write the library solutions...



 Jan 05



  parent reply Atila Neves <atila.neves gmail.com>  writes:


On Monday, 5 January 2026 at 13:40:13 UTC, jmh530 wrote:

 On Monday, 5 January 2026 at 10:20:50 UTC, Atila Neves wrote:

 [snip]

  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.


 I don't think anyone should be using features like ` live` 
 themselves and instead the language should provide the 
 features that allow one to write library solutions like smart 
 pointers.


 Anyone? Someone has the write the library solutions...


https://github.com/atilaneves/automem



 Jan 16



  parent reply jmh530 <john.michael.hall gmail.com>  writes:


On Friday, 16 January 2026 at 15:20:22 UTC, Atila Neves wrote:

 On Monday, 5 January 2026 at 13:40:13 UTC, jmh530 wrote:

 On Monday, 5 January 2026 at 10:20:50 UTC, Atila Neves wrote:

 [snip]

  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.


 I don't think anyone should be using features like ` live` 
 themselves and instead the language should provide the 
 features that allow one to write library solutions like smart 
 pointers.


 Anyone? Someone has the write the library solutions...


 https://github.com/atilaneves/automem


I was poking fun. When you say "anyone", obviously "someone" has 
to write them.

Your point is that library writers should write smart pointers 
that use  live, but users shouldn't need to worry about it. I 
don't have a sense if that is actually something that would work 
out.

Regardless, automem doesn't use  live to my knowledge...so you're 
free to incorporate  live there and let us know how it works 
out...



 Jan 16



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 17/01/2026 6:23 AM, jmh530 wrote:

 Your point is that library writers should write smart pointers that use 
  live, but users shouldn't need to worry about it. I don't have a sense 
 if that is actually something that would work out.


That isn't how  live works.

 live checks that function it is applied to and only that function.

It is applied by the user on the user's code.

Library types have NOTHING TO DO WITH IT.

I do not understand why Atila brought these types up about  live, its 
completely unrelated.



 Jan 16



prev sibling  parent  Mike Shah <mshah.475 gmail.com>  writes:


On Monday, 5 January 2026 at 10:20:50 UTC, Atila Neves wrote:

 On Monday, 15 December 2025 at 04:20:21 UTC, Mike Shah wrote:

 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.


 I don't think anyone should be using features like ` live` 
 themselves and instead the language should provide the features 
 that allow one to write library solutions like smart pointers.


I kind of use  live in what 'Soot' gave me in Java many years ago 
(Soot is a toolkit for writing program analysis for Java). Soot 
allowed you to turn on and off various types of static or dynamic 
analysis based on how much power you needed/wanted/had time for. 
If the compiler provides this to me in an easier way, I am of 
course more happy! I suspect I could rework things with llvm/ldc 
(or gdc) to write a compiler pass to annotate functions with 
 live as needed/temporarily too.

Either way, glad  live is there 🙂



 Jan 05



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 2025



 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 2025



  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 2025



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 2025



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 2025



  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 2025



 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 2025



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 2025



 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 2025



  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 2025



prev sibling next 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 2025



 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 2025



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 2025



prev sibling  parent  Quirin Schroll <qs.il.paperinik gmail.com>  writes:


On Sunday, 14 December 2025 at 20:23:51 UTC, Walter Bright 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).


As of now, in D, you can only have static arrays on the stack. 
When you do
```d
scope int[] xs = [1,2,3];
```
What you get is:
```d
int[3] __xs = [1,2,3];
int[] xs = __xs[];
```
That’s not bad, but it only works for plain literals. This fails:
```d
scope int[] xs = condition() ? [1,2] : [1,2,3];
```

Unfortunately, you can’t have actual dynamic arrays:
```d
void f(size_t n)  nogc  safe
{
     scope int[] xs = new int[](n); // error: GC-alloc in  nogc
}
```
If D had this, ` nogc` would gain a lot.


The only thing I’m unsure about is what to do if `n` is large. It 
can blow your stack. Can the compiler check beforehand if it will 
and throw an `Error`?



What D could have is a ` stackalloc` attribute for local 
variables (not function parameters):
```d
void f(size_t n)  safe
{
     scope int[] xs = new int[](n);
      stackalloc int[] ys = new int[](n);
}
```
1. `xs` will be allocated on the stack if `n` is small 
(implementation-defined), otherwise heap allocated. The idea 
being, if `n` is big, heap allocation isn’t that big of a 
performance hit anyways, but what you get is that small buffers 
are optimized to go on the stack.
2. `ys` is guaranteed to be allocated on the stack, you trade 
“pessimization, but it just works” for “guaranteed stack alloc, 
but throws Error if too big”.

Generally, ` stackalloc` implies `scope`. In a ` nogc`-annotated 
function, `new T[](…)` requires assignment to a ` stackalloc` 
local variable.

The only open question: Templates that infer ` nogc`. I’d say, if 
they use
```d
scope int[] xs = new int[](n);
```
they’re possibly allocating unless VRP can prove `n` is small 
enough.

For the time being,
```d
scope int[] xs = condition() ? [4,5] : [1,2,3];
```
can be implemented as:
```d
static int[2] l = [4,5];
static int[3] r = [1,2,3];
int[3] _xs = void;
scope int[] xs = cond()
     ? (_xs[0..2] = l[])
     : (_xs[0..3] = r[]);
```



 Jan 16



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 2025



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 2025



  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 2025



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 2025



 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 2025



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 2025



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 2025



 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 2025



  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 2025



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 2025



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 2025



 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 2025



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 2025



 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 2025



  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 2025



  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 2025



  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 2025



  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 2025



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 2025



  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 2025



 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 2025



 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 2025



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 2025



  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 2025



 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 2025



  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 2025



  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 2025



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 2025



  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 2025



  parent reply 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 2025



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


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



 Dec 21 2025



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 2025



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 2025



 next sibling 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 2025



  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 2025



 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 2025



  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 2025



  parent reply 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 2025



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/15/2025 10:05 AM, monkyyy wrote:

 You have to cast at least a single perl in front of walter.


What, no gold bars?



 Dec 19 2025



  parent  monkyyy <crazymonkyyy gmail.com>  writes:


On Saturday, 20 December 2025 at 05:15:13 UTC, Walter Bright 
wrote:

 On 12/15/2025 10:05 AM, monkyyy wrote:

 You have to cast at least a single perl in front of walter.


 What, no gold bars?


your a little old for mir and frankincense



 Dec 19 2025



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 2025



 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 2025



 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 2025



  parent reply "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 2025



  parent reply 6622 <notanemail foo.fake>  writes:


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

 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.


I use alias this on my structs a lot.

Its ideas like this that make me worry about editions regressing 
the language. Editions should be used for cleaning up the 
language, fixing up problematic semantics and ugly corners. This 
is very ugly and verbose compared to the current alias this 
syntax. Dont make D more C++ or Rust like :^)

I support removing the multiple inheritance, it snuck into the 
language unintentionally. I also hope to see the graceful 
automatic type casting into the base type stay, its useful.

If the syntax is to be changed, I liked the idea of it reusing 
the class inheretence syntax but for structs `struct Foo : 
BaseType {}`. Whatever the new syntax is, it needs to be good on 
the eyes! I have hundreds of simple structs that use alias this 
to create wrapper types, its useful for protecting from the wrong 
arguments being passed to functions & etc...



 Dec 22 2025



 next sibling parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 23/12/2025 1:29 PM, 6622 wrote:

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

 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.


 
 I use alias this on my structs a lot.
 
 Its ideas like this that make me worry about editions regressing the 
 language. Editions should be used for cleaning up the language, fixing 
 up problematic semantics and ugly corners. This is very ugly and verbose 
 compared to the current alias this syntax. Dont make D more C++ or Rust 
 like :^)


It could yes, I am worried that if we keep the same syntax it'll cause
silent breakage.

As of right now, its more likely that we'll risk the breakage instead.

For the really interesting usage of alias this, you have a method 
regardless, so if anything it shortens code down.

I'm expecting push back and then me dropping it.


 I support removing the multiple inheritance, it snuck into the language 
 unintentionally. I also hope to see the graceful automatic type casting 
 into the base type stay, its useful.
 
 If the syntax is to be changed, I liked the idea of it reusing the class 
 inheretence syntax but for structs `struct Foo : BaseType {}`. Whatever 
 the new syntax is, it needs to be good on the eyes! I have hundreds of 
 simple structs that use alias this to create wrapper types, its useful 
 for protecting from the wrong arguments being passed to functions & etc...


Struct inheritance is a separate feature.

Alias this is used for significantly more than just inheriting a struct 
and if we only do one, it'll cause some code to not have a migration 
path that needs this feature more.



 Dec 22 2025



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 12/23/25 01:29, 6622 wrote:

 
 I support removing the multiple inheritance, it snuck into the language 
 unintentionally.


a) It's not actually multiple inheritance.
b) TDPL documents that there can be more than one `alias this`.

This is not any more complicated than allowing more than one module to 
be imported...



 Dec 24 2025



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 2025



  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 2025



prev sibling  parent reply 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 2025



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/17/2025 9:35 AM, Jonathan M Davis wrote:

 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.


A couple of things about 'alias this':

1. The idea is good, but the syntax is awkward.

2. It unexpectedly introduced multiple inheritance when used with classes,
which 
was a huge mistake. There are many bugs in the buglist on this because we never 
defined how the multiple inheritance should be resolved, which is why D avoided 
MI in the first place. We could not find any sensible solution.

3. alias this works fine with structs, it just needs a better syntax.

4. we decided to leave alias this on classes alone, meaning whatever it does 
with classes is what it does. I highly recommend avoiding it with classes.

5. we have no idea how much existing code would break if we broke using alias 
this with classes

Let's not be too eager to dump everything we dislike into the first edition. 
Let's be a bit modest, at least for the first edition, and see if our edition 
design is a good one.



 Dec 19 2025



prev sibling  parent  Quirin Schroll <qs.il.paperinik gmail.com>  writes:


On Saturday, 13 December 2025 at 21:25:29 UTC, Sadiel 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 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


I get all of those, just not removing complex numbers. Complex 
numbers shouldn’t be a library feature generally for a language 
like D, but D also advertises C interop. Well, C99 has native 
complex and imaginary number support. Yes, there are asterisks, 
but by and large, they’re supported. They’re supported where D is 
supported.

The storage class `lazy` cannot easily be replaced due to 
attribute shenanigans. There is no alternative for `alias this`. 
Those two features can’t just be removed without making some 
perfectly valid things impossible. You’d have to replace them, 
and at that point, what’s stopping you from adding the feature to 
the current language?



 Jan 16



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 2025



  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 2025



  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 2025



  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 2025



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 2025



  parent reply 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 2025



  parent  Clouudy <Swergers123 gmail.com>  writes:


On Thursday, 18 December 2025 at 06:43:14 UTC, Walter Bright 
wrote:

 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.


Well then something that just makes it easier to do C bindings 
without any friction by solving this problem, if not 
auto-removing immutable.



 Dec 31 2025



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 2025



 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 2025



  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 2025



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 2025



  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 2025



  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 2025



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 2025



  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 2025



 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 2025



  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 2025



prev sibling  parent reply 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 2025



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Can you please write up a description as to how this might work in D, and post 
it to d.development.ideas?



 Dec 19 2025



  parent reply jmh530 <john.michael.hall gmail.com>  writes:


On Saturday, 20 December 2025 at 05:05:28 UTC, Walter Bright 
wrote:

 Can you please write up a description as to how this might work 
 in D, and post it to d.development.ideas?


See here
https://forum.dlang.org/post/rpqppcvebeblghmrcyjj forum.dlang.org



 Dec 21 2025



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


thank you



 Dec 21 2025



prev sibling next 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 2025



 next sibling 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 2025



  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 2025



prev sibling  parent  Quirin Schroll <qs.il.paperinik gmail.com>  writes:


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

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

 - Turn on: rvaluerefparam
 	- Known bugs:
 		- https://github.com/dlang/dmd/issues/22078


I’m not sure rvaluerefparam is universally loved.

Overloading rules must be clarified.



 Jan 16



prev sibling next sibling parent reply Guillaume Piolat <first.nam_e 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


autoencoding
lazy
complex literals still work, seems to me
Monitor



 Dec 19 2025



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 20/12/2025 2:30 AM, Guillaume Piolat wrote:

 Monitor


This is not removable with an edition, its library code that'll break D2.

Here is my proposed plan:

Decouple classes in compiler from druntime, allow custom roots.

Decouple the monitor in a root class from Object, so each root class can 
provide their own.

Decouple class/interface casting from Object.

Have each interface associate it with a root class.

Swap the root class in an edition. This new root class may not have a 
monitor.

These are not in order.

Sadly when I tried getting the first step approved Adam wasn't there and 
wasn't able to advocate for synchronized statements being necessary. You 
can't just swap them with with statements and have it work out the same 
which is not easy to understand.



 Dec 19 2025



  parent reply sighoya <sighoya gmail.com>  writes:


On Friday, 19 December 2025 at 17:28:43 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 Here is my proposed plan:

 Decouple classes in compiler from druntime, allow custom roots.

 Decouple the monitor in a root class from Object, so each root 
 class can provide their own.

 Decouple class/interface casting from Object.

 Have each interface associate it with a root class.

 Swap the root class in an edition. This new root class may not 
 have a monitor.

 These are not in order.


How does it work if you pass an object to a module with an older 
edition expecting a specific root class and also when you receive 
a newly created object from the said module?



 Dec 20 2025



  parent reply Derek Fawcus <dfawcus+dlang employees.org>  writes:


On Saturday, 20 December 2025 at 10:59:52 UTC, sighoya wrote:

 On Friday, 19 December 2025 at 17:28:43 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 Here is my proposed plan:




[...]


 How does it work if you pass an object to a module with an 
 older edition expecting a specific root class and also when you 
 receive a newly created object from the said module?


Would it maybe require changing the D name mangling scheme when 
generating code in such cases so that the symbols simply fail to 
link if/when cross-edition incompatible code is mixed?

DF



 Dec 20 2025



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 21/12/2025 12:33 AM, Derek Fawcus wrote:

 On Saturday, 20 December 2025 at 10:59:52 UTC, sighoya wrote:

 On Friday, 19 December 2025 at 17:28:43 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 Here is my proposed plan:




 
 [...]
 

 How does it work if you pass an object to a module with an older 
 edition expecting a specific root class and also when you receive a 
 newly created object from the said module?




It will error.

Just like with any other type, including extern(C++) classes.

 Would it maybe require changing the D name mangling scheme when 
 generating code in such cases so that the symbols simply fail to link 
 if/when cross-edition incompatible code is mixed?
 
 DF


This is far too complex for the problem at hand.

A class hierarchy is determined at the point of declaration.

It does not changed based upon who imports it.

As long as the module is known what its edition is, and the class 
declaration for both itself and any parents are kept in good state, 
it'll remain the same.



 Dec 20 2025



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,


Maybe worth to carefully check the video 
https://www.youtube.com/watch?v=7fGB-hjc2Gc
and fix (if any issues are presented in D as well) in Editions



 Dec 22 2025



 next sibling parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 23/12/2025 9:07 AM, Sergey wrote:

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

 Now that Editions have been implemented (thanks Atila, Dennis,


 
 Maybe worth to carefully check the video https://www.youtube.com/watch? 
 v=7fGB-hjc2Gc
 and fix (if any issues are presented in D as well) in Editions


You are evil.
I watched that video and hated every second of it.
:P

In other news I'm adding a new form of case statements to my list.

``case Foo statement;``

That is the only feature that could be desirable, because honestly so 
often so many of our case statements could actually be one liners like 
this if it weren't for needing a break.



 Dec 22 2025



prev sibling  parent  claptrap <clap trap.com>  writes:


On Monday, 22 December 2025 at 20:07:01 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,


 Maybe worth to carefully check the video 
 https://www.youtube.com/watch?v=7fGB-hjc2Gc
 and fix (if any issues are presented in D as well) in Editions


Unfortunately i think Walter spent too many years with C++. He's 
"got used" to a lot of the ugly crap and cant see it for what it 
is anymore.



 Dec 22 2025



prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists 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.



Please could we finally fix ` property`

Also see the OpenD changes list:

https://opendlang.org/changes.html



 Dec 24 2025



 next sibling parent reply Kapendev <alexandroskapretsos gmail.com>  writes:


On Wednesday, 24 December 2025 at 11:32:05 UTC, Vladimir 
Panteleev 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.



 Please could we finally fix ` property`

 Also see the OpenD changes list:

 https://opendlang.org/changes.html


No idea about ` property`, but here are some things I like about 
OpenD:

- named unittests
- ` implicit this()` constructors
- `import()` expressions can now, by default, load files from the 
defining module's source directory
- pragma(linkerDirective) and  section now work on dmd similarly 
to ldc
- [parser] `with(auto x = expr) { ... }` added

I didn't mention some because they are already in D now. The last 
one is probably coming too I think.



 Dec 24 2025



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Wednesday, 24 December 2025 at 15:29:18 UTC, Kapendev wrote:

 No idea about ` property`, but here are some things I like 
 about OpenD:


What I'd specifically like to do with ` property`, but note that 
I have tried and failed to implement it twice over the years, so 
don't hold your breath, is, in order of priority:

1) Make it so `struct A {  property Callable foo(); }` works when 
you do `A a; a.foo();` so that calls the returned callable, not 
just gets it. Currently, to call the returned callable, you must 
do `a.foo()();` which shatters the illusion.

If this alone could change, I'd be pretty happy!

2) Make it so a getter/setter pair is called when you do `a.prop 
+= 5;`. Ideally, this would automagically call `a.prop(a.prop + 
5)`.

This is just a nice to have sometimes, but if we can make it so, 
that'd be cool. Some people will argue this breaks the atomic 
assumption of +=, but tbh you shouldn't assume += is atomic in 
the first place, so meh.

3) I'm not in love with the typeof(a.prop) thing but im not sure 
it is worth changing even if we limited the breakage so .... idk.


I think this is it, I'm sure I've written about this a few times 


Everything else is meh.

I absolutely do NOT want to change the current behavior of 
optional parenthesis on non-property functions and I do NOT care 
about `writeln = 5`. Like whatever.



 Dec 24 2025



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Wednesday, 24 December 2025 at 18:10:52 UTC, Adam D. Ruppe 
wrote:

 On Wednesday, 24 December 2025 at 15:29:18 UTC, Kapendev wrote:
 What I'd specifically like to do with ` property`, but note 
 that I have tried and failed to implement it twice over the 
 years, so don't hold your breath, is, in order of priority:


[...]

Your list looks good; one thing I'd add is that if you have 
` property ref int foo()` then `&foo` should get you an `int*`.



 Dec 24 2025



 next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 25/12/2025 1:04 PM, Vladimir Panteleev wrote:

 On Wednesday, 24 December 2025 at 18:10:52 UTC, Adam D. Ruppe wrote:

 On Wednesday, 24 December 2025 at 15:29:18 UTC, Kapendev wrote:
 What I'd specifically like to do with ` property`, but note that I 
 have tried and failed to implement it twice over the years, so don't 
 hold your breath, is, in order of priority:


 
 [...]
 
 Your list looks good; one thing I'd add is that if you have ` property 
 ref int foo()` then `&foo` should get you an `int*`.


Please do an ideas thread on what is wanted.

As of right now, what I consider "fixing  property" to mean is removal.



 Dec 24 2025



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 12/25/25 02:25, Richard (Rikki) Andrew Cattermole wrote:

 On 25/12/2025 1:04 PM, Vladimir Panteleev wrote:

 On Wednesday, 24 December 2025 at 18:10:52 UTC, Adam D. Ruppe wrote:

 On Wednesday, 24 December 2025 at 15:29:18 UTC, Kapendev wrote:
 What I'd specifically like to do with ` property`, but note that I 
 have tried and failed to implement it twice over the years, so don't 
 hold your breath, is, in order of priority:


 [...]

 Your list looks good; one thing I'd add is that if you have ` property 
 ref int foo()` then `&foo` should get you an `int*`.


 
 Please do an ideas thread on what is wanted.
 
 As of right now, what I consider "fixing  property" to mean is removal.
 


That would clearly be referred to as "removing  property", so you are 
misunderstanding what was said.

Anyway, I don't have anything new to say:
https://wiki.dlang.org/DIP24



 Dec 24 2025



 next sibling parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 12/25/25 04:51, Timon Gehr wrote:

 
 
 Anyway, I don't have anything new to say:
 https://wiki.dlang.org/DIP24


(You can ignore the section that is not about ` property`, I don't 
actually mind `writeln = 5;`.)



 Dec 24 2025



prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 25/12/2025 4:51 PM, Timon Gehr wrote:

 On 12/25/25 02:25, Richard (Rikki) Andrew Cattermole wrote:

 On 25/12/2025 1:04 PM, Vladimir Panteleev wrote:

 On Wednesday, 24 December 2025 at 18:10:52 UTC, Adam D. Ruppe wrote:

 On Wednesday, 24 December 2025 at 15:29:18 UTC, Kapendev wrote:
 What I'd specifically like to do with ` property`, but note that I 
 have tried and failed to implement it twice over the years, so don't 
 hold your breath, is, in order of priority:


 [...]

 Your list looks good; one thing I'd add is that if you have 
 ` property ref int foo()` then `&foo` should get you an `int*`.


 Please do an ideas thread on what is wanted.

 As of right now, what I consider "fixing  property" to mean is removal.


 
 That would clearly be referred to as "removing  property", so you are 
 misunderstanding what was said.


I didn't misunderstand it.

What one person consider fixing  property isn't the same thing as what 
others think fixing  property is.

Hence me asking for an ideas thread to make it all explicit what is 
being intended here.



 Dec 24 2025



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 12/25/25 04:56, Richard (Rikki) Andrew Cattermole wrote:

 On 25/12/2025 4:51 PM, Timon Gehr wrote:

 On 12/25/25 02:25, Richard (Rikki) Andrew Cattermole wrote:

 On 25/12/2025 1:04 PM, Vladimir Panteleev wrote:

 On Wednesday, 24 December 2025 at 18:10:52 UTC, Adam D. Ruppe wrote:

 On Wednesday, 24 December 2025 at 15:29:18 UTC, Kapendev wrote:
 What I'd specifically like to do with ` property`, but note that I 
 have tried and failed to implement it twice over the years, so 
 don't hold your breath, is, in order of priority:


 [...]

 Your list looks good; one thing I'd add is that if you have 
 ` property ref int foo()` then `&foo` should get you an `int*`.


 Please do an ideas thread on what is wanted.

 As of right now, what I consider "fixing  property" to mean is removal.


 That would clearly be referred to as "removing  property", so you are 
 misunderstanding what was said.


 
 I didn't misunderstand it.
 ...


You can't fix something by removing it, it's an alternative action.


 What one person consider fixing  property isn't the same thing as what 
 others think fixing  property is.
 ...


I think there is a relatively canonical answer to what that means and a 
little bit of thought and experience with the shortcomings of the 
existing design easily reveals it.



 Dec 24 2025



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 12/25/25 04:51, Timon Gehr wrote:

 
 
 Anyway, I don't have anything new to say:
 https://wiki.dlang.org/DIP24


Actually it seems this writeup failed to describe the case of assignment 
through a `ref` property. That should still work (already works now). 
Otherwise I think it's fine.



 Dec 24 2025



prev sibling  parent reply Dom Disc <dominikus scherkl.de>  writes:


On Thursday, 25 December 2025 at 00:04:05 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 24 December 2025 at 18:10:52 UTC, Adam D. Ruppe 
 wrote:
 [...]

 Your list looks good; one thing I'd add is that if you have 
 ` property ref int foo()` then `&foo` should get you an `int*`.


There is one more thing that I would wish from  property:

If I write a  property template, it should be callable by 
T.myProp instead of myProp!T, so that it is not distinct from 
"buildin" properies of a type. This would make it much easier to 
write generic code using them.



 Dec 31



  parent reply Paul Backus <snarwin gmail.com>  writes:


On Thursday, 1 January 2026 at 00:33:13 UTC, Dom Disc wrote:

 On Thursday, 25 December 2025 at 00:04:05 UTC, Vladimir 
 Panteleev wrote:

 On Wednesday, 24 December 2025 at 18:10:52 UTC, Adam D. Ruppe 
 wrote:
 [...]

 Your list looks good; one thing I'd add is that if you have 
 ` property ref int foo()` then `&foo` should get you an `int*`.


 There is one more thing that I would wish from  property:

 If I write a  property template, it should be callable by 
 T.myProp instead of myProp!T, so that it is not distinct from 
 "buildin" properies of a type. This would make it much easier 
 to write generic code using them.


This already works lol.

```d
struct S {}
 property int foo(T)(T t) => 123;

void main()
{
     S s;
     assert(s.foo == 123); // ok
}
```



 Jan 04



  parent reply Dom Disc <dominikus scherkl.de>  writes:


On Sunday, 4 January 2026 at 20:18:04 UTC, Paul Backus wrote:

 On Thursday, 1 January 2026 at 00:33:13 UTC, Dom Disc wrote:

 If I write a  property template, it should be callable by 
 T.myProp instead of myProp!T [...]


 This already works lol.

 ```d
 struct S {}
  property int foo(T)(T t) => 123;

 void main()
 {
     S s;
     assert(s.foo == 123); // ok
 }
 ```


No, this is clear.
What I mean is: I can call int.max (on the type, not a variable 
of that type) and I can call myType.max (if myType provides a 
static property "max").

But if I write
```d
static  property template invalid(T) if(isNumeric!T)
{
    static if(isFloatingPoint!T)
       enum invalid = T.init;
    else static if(isSigned!T)
       enum invalid = T.min; // 0x80..00
    else // unsigned
       enum invalid = T.max; // 0xFF..FF
    else static if(is(Unqual!T==bool))
       enum invalid = false;
}

struct myType
{
    int static  property invalid() { return 0xDeadBeef; }
}
```
Then I must call the first with "invalid!int" but the second with 
"myType.invalid".
But it's a new property of all numeric types, so I want to call 
the first also with "int.invalid" instead of always needing to 
distinguish between builtin types and custom types.



 Jan 04



  parent  Dom Disc <dominikus scherkl.de>  writes:


On Sunday, 4 January 2026 at 22:11:55 UTC, Dom Disc wrote:
Damn it. Forget the case with bool. Should be:

```d
static  property template invalid(T) if(isNumeric!T)
{
    static if(isFloatingPoint!T)
       enum invalid = T.init;
    else static if(isSigned!T)
       enum invalid = T.min; // 0x80..00
    else // unsigned
       enum invalid = T.max; // 0xFF..FF
}
```

(and of course today it's not valid to write "static  property" 
before a template - this is what I wish would be changed)



 Jan 04



prev sibling next sibling parent  Dom Disc <dominikus scherkl.de>  writes:


On Wednesday, 24 December 2025 at 11:32:05 UTC, Vladimir 
Panteleev wrote:

 Please could we finally fix ` property`


Yes, this!



 Dec 24 2025



prev sibling  parent reply Richard (Rikki) Andrew Cattermole <richard cattermole.co.nz>  writes:


On Wednesday, 24 December 2025 at 11:32:05 UTC, Vladimir 
Panteleev 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.



 Please could we finally fix ` property`

 Also see the OpenD changes list:

 https://opendlang.org/changes.html


Here are my notes on this:

- Fix `` property``
	- It is not property functions, it is a named expression with 
zero or one arguments. The confusion of its scope has been solely 
due to this problem. Rename it to `` namedexpr``
	- Once `` namedexpr`` is applied to an overload set, either all 
members in the overload set must be `` namedexpr`` or none of 
them.
		- This is required to ensure that behavior is consistent 
between all functions for a given named expression.
	- Lower getter function calls to: ``auto val = func(), val``, 
use by-ref if it returns by-ref.
		- This makes ``&func`` become ``typeof(ReturnType!func)`` not 
``typeof(func)``.
		- Use ``&__traits(getOverloads`` to get the actual function 
pointer.
		- This allows:
			```d
			struct A {
				 namedexpr Callable foo();
			}
			A a;
			a.foo();
			```
		- If a gotten from value has been mutated and it is not by-ref 
(i.e. mutable function call on it), call the modify-in-place 
setter. In the form of: ``void func(ref T val)``
			- I.e.
			```d
			// func++;
			auto val = func(), val++, func(val);
			```
			- Do not use the setter, use the modify-in-place setter 
instead. If you use the setter you will need more temporaries if 
the type changes, or make it inaccessible if it returns void.



 Dec 25 2025



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Thursday, 25 December 2025 at 22:33:28 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 Rename it to `` namedexpr``


No thanks

One of the reason people mentioned they were turned off by D is 
weird naming decisions like using `enum` for manifest constants. 
Good names matter; familiar names are good, even if semantics are 
slightly different

Just fix ` property`, don't invent more features that are kinda 
like other features and you have to know which one to use in 
which situation / language version


 		- If a gotten from value has been mutated and it is not 
 by-ref (i.e. mutable function call on it), call the 
 modify-in-place setter. In the form of: ``void func(ref T val)``


Why?

AFAIK `someDynamicArray.length++` works fine by get+set and the 
sky didn't fall

What other language does it this way?



 Dec 25 2025



 next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 26/12/2025 1:48 PM, Vladimir Panteleev wrote:

 On Thursday, 25 December 2025 at 22:33:28 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 Rename it to `` namedexpr``


 
 No thanks
 
 One of the reason people mentioned they were turned off by D is weird 
 naming decisions like using `enum` for manifest constants. Good names 
 matter; familiar names are good, even if semantics are slightly different


They do yes and that is the exact problem with  property.

It does not mean what we have it doing.


up consistently over a very long period of time and nothing has been 
done to progress it.


 Just fix ` property`, don't invent more features that are kinda like 
 other features and you have to know which one to use in which 
 situation / language version


Its not a new feature, its a renamed feature that is now being completed 
using simpler rules than what was described in DIP24 to archive the same 
thing.


         - If a gotten from value has been mutated and it is not by-ref 
 (i.e. mutable function call on it), call the modify-in-place setter. 
 In the form of: ``void func(ref T val)``


 
 Why?
 
 AFAIK `someDynamicArray.length++` works fine by get+set and the sky 
 didn't fall
 
 What other language does it this way?


As per what Timon wants:

" 4. OpAssign position: prop op= exp
  -- In this case, the whole expression is rewritten to {auto val=prop; 
val op= exp; return prop=val; }(), where 'val' is choosen such that it 
does not occur free in exp or prop."

https://wiki.dlang.org/DIP24

Doing that with a by-value setter is going to have the problems I 
explained, it'll need to be the in place kind instead which takes it by-ref.



 Dec 25 2025



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Friday, 26 December 2025 at 00:57:52 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 They do yes and that is the exact problem with  property.

 It does not mean what we have it doing.


 has come up consistently over a very long period of time and 
 nothing has been done to progress it.


I don't see the problem.

I stand by what I said


 Just fix ` property`, don't invent more features that are 
 kinda like other features and you have to know which one to 
 use in which situation / language version


 Its not a new feature, its a renamed feature that is now being 
 completed using simpler rules than what was described in DIP24 
 to archive the same thing.


I can see what you mean but surely you realize that this is not 
how the rest of the world will see it. You say ` namedexpr`, the 
world says "Huh?"

This will not lead to any wins


 As per what Timon wants:


I don't see how you got to that conclusion


 " 4. OpAssign position: prop op= exp
  -- In this case, the whole expression is rewritten to {auto 
 val=prop; val op= exp; return prop=val; }(), where 'val' is 
 choosen such that it does not occur free in exp or prop."


LGTM


 If you use the setter you will need more temporaries if the 
 type changes,


So don't allow the type to change?


 or make it inaccessible if it returns void.


I think that is perfectly fine? void-returning setters should be 
discouraged for copyable types, but are exactly correct for 
non-copyable types



 Dec 25 2025



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 26/12/2025 2:14 PM, Vladimir Panteleev wrote:

 On Friday, 26 December 2025 at 00:57:52 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 " 4. OpAssign position: prop op= exp
  -- In this case, the whole expression is rewritten to {auto val=prop; 
 val op= exp; return prop=val; }(), where 'val' is choosen such that it 
 does not occur free in exp or prop."


 
 LGTM
 

 If you use the setter you will need more temporaries if the type changes,


 
 So don't allow the type to change?
 

 or make it inaccessible if it returns void.


 
 I think that is perfectly fine? void-returning setters should be 
 discouraged for copyable types, but are exactly correct for non-copyable 
 types


The issue with both of these is they are additional special case rules.
This is something that is discouraged where possible and it is possible 
here.

Whereas what I proposed is a simple 1:1 swap of something that would 
have to exist for it to work.



 Dec 25 2025



prev sibling next sibling parent reply Adam Wilson <flyboynw gmail.com>  writes:


On Friday, 26 December 2025 at 00:48:54 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 25 December 2025 at 22:33:28 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 Rename it to `` namedexpr``


 No thanks

 One of the reason people mentioned they were turned off by D is 
 weird naming decisions like using `enum` for manifest 
 constants. Good names matter; familiar names are good, even if 
 semantics are slightly different


I also told him in DM's that nobody is going to know what that 
name means. I sure don't.

Names have become a focus point of mine while working on Phobos 
3. JMD will tell you that I can be super picky. But your 
reasoning is sound. Names need to be familiar even if they are 
slightly different.





 Dec 26 2025



  parent reply libxmoc <libxmoc gmail.com>  writes:


On Friday, 26 December 2025 at 17:53:49 UTC, Adam Wilson wrote:

 On Friday, 26 December 2025 at 00:48:54 UTC, Vladimir Panteleev 
 wrote:

 On Thursday, 25 December 2025 at 22:33:28 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 Rename it to `` namedexpr``


 No thanks

 One of the reason people mentioned they were turned off by D 
 is weird naming decisions like using `enum` for manifest 
 constants. Good names matter; familiar names are good, even if 
 semantics are slightly different


 I also told him in DM's that nobody is going to know what that 
 name means. I sure don't.

 Names have become a focus point of mine while working on Phobos 
 3. JMD will tell you that I can be super picky. But your 
 reasoning is sound. Names need to be familiar even if they are 
 slightly different.





Why bloat global scope and reserve names?

```
import utils = myapp.utilities;


void main()
{
     utils.thing();
}
```

Solved.

None of that would matter if D had a specific way to use builtins.

Example:

```

struct Actor
{
      :property // : = builtin
     int hp();

}
```

This way, language maintainers could use whatever names they want 
without forcing users to cede common identifiers.

That's what I like about Zig, zero reserved keywords.



 Dec 27 2025



  parent reply Paul Backus <snarwin gmail.com>  writes:


On Saturday, 27 December 2025 at 14:00:19 UTC, libxmoc wrote:

 None of that would matter if D had a specific way to use 
 builtins.

 Example:

 ```

 struct Actor
 {
      :property // : = builtin
     int hp();

 }
 ```

 This way, language maintainers could use whatever names they 
 want without forcing users to cede common identifiers.


D already has a solution for this: compiler-recognized UDAs in 
`core.attribute`.

```d
// If 'property' weren't reserved, this could work
import core.attribute: property;

struct Actor
{
      property int hp();
}
```

The only thing keeping us from migrating existing attributes to 
`core.attribute` is backwards compatibility--existing code would 
be forced to add `import` statements to avoid breakage. But with 
editions, making a change like this is probably feasible.



 Dec 27 2025



  parent reply libxmoc <libxmoc gmail.com>  writes:


On Saturday, 27 December 2025 at 15:33:23 UTC, Paul Backus wrote:

 On Saturday, 27 December 2025 at 14:00:19 UTC, libxmoc wrote:

 None of that would matter if D had a specific way to use 
 builtins.

 Example:

 ```

 struct Actor
 {
      :property // : = builtin
     int hp();

 }
 ```

 This way, language maintainers could use whatever names they 
 want without forcing users to cede common identifiers.


 D already has a solution for this: compiler-recognized UDAs in 
 `core.attribute`.

 ```d
 // If 'property' weren't reserved, this could work
 import core.attribute: property;

 struct Actor
 {
      property int hp();
 }
 ```

 The only thing keeping us from migrating existing attributes to 
 `core.attribute` is backwards compatibility--existing code 
 would be forced to add `import` statements to avoid breakage. 
 But with editions, making a change like this is probably 
 feasible.


It makes builtins look identical to user code, you can't tell 
 property is special without checking imports, and that's bad.

Language features deserve syntax that signals their status.

It's the perfect opportunity for Editions to finally address this 
long standing issue.

The renamed import solution proves it can be solved elegantly.



 Dec 27 2025



  parent  Kapendev <alexandroskapretsos gmail.com>  writes:


On Saturday, 27 December 2025 at 18:43:29 UTC, libxmoc wrote:

 It makes builtins look identical to user code, you can't tell 
  property is special without checking imports, and that's bad.


It's namespacing some keywords under ` `, like instead of `pure` 
you do ` pure`. I kinda like the idea.



 Dec 28 2025



prev sibling  parent  claptrap <clap trap.com>  writes:


On Friday, 26 December 2025 at 00:48:54 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 25 December 2025 at 22:33:28 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 Rename it to `` namedexpr``


 No thanks

 One of the reason people mentioned they were turned off by D is 
 weird naming decisions like using `enum` for manifest constants.


Yes but we absolutely must not add any more keywords, the English 
language only has 170,000  and I'm pretty sure we're running low.



 Dec 26 2025



prev sibling next sibling parent reply IchorDev <zxinsworld 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.


One big thing I'd love would be for us to stop requiring a 
`break` at the end of each `case`; instead a case should default 
to breaking at the end, which is what you want 99% of the time. 
We already require an explicit `goto case` for fall-through, and 
give an error otherwise, so this won't break existing code.
Switch-case statements with short cases are so much nicer to read 
without all the redundant `break`s everywhere:

```d
int x = 1;
switch(x){
	case 0:
		writeln("hi");
	case 1:
		writeln("bye");
	default:
		writeln("invalid code!");
}
```



 Jan 10



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Sunday, 11 January 2026 at 06:47:42 UTC, IchorDev wrote:

 One big thing I'd love would be for us to stop requiring a 
 `break` at the end of each `case`; instead a case should 
 default to breaking at the end, which is what you want 99% of 
 the time. We already require an explicit `goto case` for 
 fall-through, and give an error otherwise, so this won't break 
 existing code.


I don't think this is going to happen due to C source 
compatibility being one of the design goals of D - if you paste 
in C code, it should either compile and work in the same way, or 
fail to compile. C has implicit fallthrough (which is presumably 
used intentionally) so it would be the exactly same syntax in 
both C and D but which do very different things. The most likely 
way towards improving this is probably a new pattern-matching 
syntax to replace the C-like switch/case.


 Switch-case statements with short cases are so much nicer to 
 read without all the redundant `break`s everywhere:


I've been doing this a lot:

```d
int x = 1;
string result = {
	switch(x) {
		case 0:
			return "hi";
		case 1:
			return "bye";
		default:
			return "invalid code!";
	}
}();
writeln(result);
```



 Jan 11



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 12/01/2026 3:15 AM, Vladimir Panteleev wrote:

 On Sunday, 11 January 2026 at 06:47:42 UTC, IchorDev wrote:

 One big thing I'd love would be for us to stop requiring a `break` at 
 the end of each `case`; instead a case should default to breaking at 
 the end, which is what you want 99% of the time. We already require an 
 explicit `goto case` for fall-through, and give an error otherwise, so 
 this won't break existing code.


 
 I don't think this is going to happen due to C source compatibility 
 being one of the design goals of D - if you paste in C code, it should 
 either compile and work in the same way, or fail to compile. C has 
 implicit fallthrough (which is presumably used intentionally) so it 
 would be the exactly same syntax in both C and D but which do very 
 different things. The most likely way towards improving this is probably 
 a new pattern-matching syntax to replace the C-like switch/case.


 From my edition meeting notes:

- Single statement case, does not need a break.
	- ``case Foo statement;``

This should work, replacing the colon with the statement.

Not valid C, and shouldn't impact existing code.



 Jan 11



  parent reply user1234 <user1234 12.de>  writes:


On Monday, 12 January 2026 at 01:50:13 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 - Single statement case, does not need a break.
 	- ``case Foo statement;``

 This should work, replacing the colon with the statement.

 Not valid C, and shouldn't impact existing code.


Let's bikeshed... keep the colon, add the FinalCaseStatement to 
the AST:

```
FinalCaseStatement ::=  "final" "case" ":" Statement
```



 Jan 12



  parent  user1234 <user1234 12.de>  writes:


On Monday, 12 January 2026 at 09:53:25 UTC, user1234 wrote:

 On Monday, 12 January 2026 at 01:50:13 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 - Single statement case, does not need a break.
 	- ``case Foo statement;``

 This should work, replacing the colon with the statement.

 Not valid C, and shouldn't impact existing code.


 Let's bikeshed... keep the colon, add the FinalCaseStatement to 
 the AST:

 ```
 FinalCaseStatement ::=  "final" "case" ":" Statement
 ```


```
FinalCaseStatement ::=  "final" "case" Expression ":" Statement
```



 Jan 12



prev sibling next sibling parent  Quirin Schroll <qs.il.paperinik 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


Burn `const int f()` for member functions with fire. Require `int 
f() const`.



 Jan 16



prev sibling next sibling parent  Quirin Schroll <qs.il.paperinik 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.


Fix delegates. When in doubt, ask Timon Gehr.

Bottom line: `const(R delegate(…))` must not be invoked as 
`const` applies to the context pointer. This is one of the 
biggest holes in the type system.



 Jan 16



prev sibling  parent reply Quirin Schroll <qs.il.paperinik 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.


Replace magic properties with keywords and traits. For example, 
`T.init` should be `default(T)`. The problem is that you can 
define an eponymous member. `T.sizeof` should be 
`__traits(sizeof, T)`.



 Jan 16



  parent reply Nick Treleaven <nick geany.org>  writes:


On Friday, 16 January 2026 at 18:23:05 UTC, Quirin Schroll wrote:

 Replace magic properties with keywords and traits. For example, 
 `T.init` should be `default(T)`. The problem is that you can 
 define an eponymous member.


I think removing support in an edition for `.init` would be very 
disruptive. Why not just ban redefining it?
https://github.com/dlang/dmd/issues/18386


 `T.sizeof` should be `__traits(sizeof, T)`.


Redefining `sizeof` is already an error.



 Jan 16



 next sibling parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 17/01/2026 9:59 AM, Nick Treleaven wrote:

 On Friday, 16 January 2026 at 18:23:05 UTC, Quirin Schroll wrote:
 
     Replace magic properties with keywords and traits. For example, |
     T.init| should be |default(T)|. The problem is that you can define
     an eponymous member.
 
 I think removing support in an edition for |.init| would be very 
 disruptive. Why not just ban redefining it? https://github.com/dlang/ 
 dmd/issues/18386 <https://github.com/dlang/dmd/issues/18386>
 


Already in my list to ban it.



 Jan 16



prev sibling  parent reply libxmoc <libxmoc gmail.com>  writes:


On Friday, 16 January 2026 at 20:59:02 UTC, Nick Treleaven wrote:

 On Friday, 16 January 2026 at 18:23:05 UTC, Quirin Schroll 
 wrote:

 Replace magic properties with keywords and traits. For 
 example, `T.init` should be `default(T)`. The problem is that 
 you can define an eponymous member.


 I think removing support in an edition for `.init` would be 
 very disruptive. Why not just ban redefining it?
 https://github.com/dlang/dmd/issues/18386


 `T.sizeof` should be `__traits(sizeof, T)`.


 Redefining `sizeof` is already an error.


In C and virtually every other language, naming a function `init` 
is extremely common. In D, defining an `init` symbol clashes with 
the built-in `.init` property.

Rather than outright banning `init` as an identifier, an edition 
is the perfect opportunity to finally return this name to users.

I propose: ` init(T)` or `__traits(init, T)` as the replacement.



 Jan 16



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 17/01/2026 8:27 PM, libxmoc wrote:

 On Friday, 16 January 2026 at 20:59:02 UTC, Nick Treleaven wrote:

 On Friday, 16 January 2026 at 18:23:05 UTC, Quirin Schroll wrote:

 Replace magic properties with keywords and traits. For example, 
 `T.init` should be `default(T)`. The problem is that you can define 
 an eponymous member.


 I think removing support in an edition for `.init` would be very 
 disruptive. Why not just ban redefining it?
 https://github.com/dlang/dmd/issues/18386


 `T.sizeof` should be `__traits(sizeof, T)`.


 Redefining `sizeof` is already an error.


 
 In C and virtually every other language, naming a function `init` is 
 extremely common. In D, defining an `init` symbol clashes with the 
 built-in `.init` property.
 
 Rather than outright banning `init` as an identifier, an edition is the 
 perfect opportunity to finally return this name to users.
 
 I propose: ` init(T)` or `__traits(init, T)` as the replacement.


Unlike C, D default initializers variables, and has meta-programming.

The init property of a type is heavily used, removing it or swapping it 
for a trait is not an option.

Also that   syntax you come up with, conflicts with UDA's, and would be 
seen as a function call.



 Jan 16