digitalmars.D - Memory Safe Programming
- GB (4/4) Aug 16 It's primarly about memory safety in C, but D gets a mention in
- user1234 (9/14) Aug 16 This was proposed as DIP 1028 which was not accepted.
- Kapendev (2/18) Aug 17 I am in team safe by default and float/double.init = 0.
- H. S. Teoh (6/26) Aug 17 Pretty sure someone could convince Adam to make OpenD @safe by default
- Adam D. Ruppe (9/11) Aug 17 Tried it, and it was a complete failure. @safe by default is
- libxmoc (7/12) Aug 17 Memory safety is best when it is intentionally, forcing it
- GB (13/27) Aug 17 C: the programmer must maintain the invariant. The result?
- Dukc (31/35) Aug 17 There actually was [a decision to make it the default, which was
- Walter Bright (2/3) Aug 17 I think we agreed that going "safer" by default was a good candidate for...
- Dukc (16/20) Aug 19 Where? Saw no mention of that. When the switch was discussed last
- Nick Treleaven (9/25) Aug 17 The solution is to make declaring a foreign linkage function
It's primarly about memory safety in C, but D gets a mention in the Appendix I. But it raises the question: why isn't safe not the default in D? https://strawberry9.github.io/the-wrong-memory
Aug 16
On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:It's primarly about memory safety in C, but D gets a mention in the Appendix I. But it raises the question: why isn't safe not the default in D? https://strawberry9.github.io/the-wrong-memoryThis was proposed as DIP 1028 which was not accepted. - https://forum.dlang.org/thread/raq4fg$1ab4$1 digitalmars.com - https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1028.md TLDR; if my memory serves me right the problem was that such a choice should have been done since day 1. D2 first realease date is early 2010's. DIP 1028 was 10 years after. Too late. Too much breakage in the eco-system.
Aug 16
On Sunday, 16 August 2026 at 09:30:09 UTC, user1234 wrote:On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:I am in team safe by default and float/double.init = 0.It's primarly about memory safety in C, but D gets a mention in the Appendix I. But it raises the question: why isn't safe not the default in D? https://strawberry9.github.io/the-wrong-memoryThis was proposed as DIP 1028 which was not accepted. - https://forum.dlang.org/thread/raq4fg$1ab4$1 digitalmars.com - https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1028.md TLDR; if my memory serves me right the problem was that such a choice should have been done since day 1. D2 first realease date is early 2010's. DIP 1028 was 10 years after. Too late. Too much breakage in the eco-system.
Aug 17
On Mon, Aug 17, 2026 at 03:45:29PM +0000, Kapendev via Digitalmars-d wrote:On Sunday, 16 August 2026 at 09:30:09 UTC, user1234 wrote:Pretty sure someone could convince Adam to make OpenD safe by default with not much consequence. ;-) T -- Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:I am in team safe by default and float/double.init = 0.It's primarly about memory safety in C, but D gets a mention in the Appendix I. But it raises the question: why isn't safe not the default in D? https://strawberry9.github.io/the-wrong-memoryThis was proposed as DIP 1028 which was not accepted. - https://forum.dlang.org/thread/raq4fg$1ab4$1 digitalmars.com - https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1028.md TLDR; if my memory serves me right the problem was that such a choice should have been done since day 1. D2 first realease date is early 2010's. DIP 1028 was 10 years after. Too late. Too much breakage in the eco-system.
Aug 17
Adam D. Ruppe <destructionator gmail.com> On Monday, 17 August 2026 at 16:26:32 UTC, H. S. Teoh wrote:Pretty sure someone could convince Adam to make OpenD safe by default with not much consequence. ;-)Tried it, and it was a complete failure. safe by default is never going to happen, certainly not in OpenD, and I find it extremely unlikely upstream will either in any edition. Inferred safe also doesn't work. https://dpldocs.info/this-week-in-arsd/Blog.Posted_2024_03_11.html What *does* work is safe*r* by default. Enable some of the highest benefit/cost ratio checks and leave the rest alone: https://dpldocs.info/this-week-in-arsd/Blog.Posted_2024_03_25.html
Aug 17
On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:It's primarly about memory safety in C, but D gets a mention in the Appendix I. But it raises the question: why isn't safe not the default in D? https://strawberry9.github.io/the-wrong-memoryMemory safety is best when it is intentionally, forcing it everywhere by default usually achieves the opposite of its goal by adding unnecessary friction D shouldn't try to replicate Rust, its real strength is ipragmatism, giving the flexibility to opt into safety where it matters without imposing it where it doesn't
Aug 17
On Monday, 17 August 2026 at 16:21:39 UTC, libxmoc wrote:On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:C: the programmer must maintain the invariant. The result? See: https://strawberry9.github.io/the-wrong-memory/Appendix_02.html D safe subset: the programmer must stay within a subset whose rules maintain the invariant. A stronger design: the language's semantics make the invariant unavoidable, except at explicitly identified escape boundaries. 'Safe by default' is not the same thing as 'safety is a language property.' C++ made the mistake of trying to have a 'safe subset' without making the subset's invariants fundamental to the language itself. Did D make the same mistake?It's primarly about memory safety in C, but D gets a mention in the Appendix I. But it raises the question: why isn't safe not the default in D? https://strawberry9.github.io/the-wrong-memoryMemory safety is best when it is intentionally, forcing it everywhere by default usually achieves the opposite of its goal by adding unnecessary friction D shouldn't try to replicate Rust, its real strength is ipragmatism, giving the flexibility to opt into safety where it matters without imposing it where it doesn't
Aug 17
On Tuesday, 18 August 2026 at 00:17:36 UTC, GB wrote:On Monday, 17 August 2026 at 16:21:39 UTC, libxmoc wrote:Depends :TM: + safety is more of a skill issue than a language mistake. Even for C, you could write code in a safe subset + follow a style guide. Most people don't do it because it's not fun or they learn the wrong things from random C projects. From my experience D makes safety fun. Slices are part of the language, for example.On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:C: the programmer must maintain the invariant. The result? See: https://strawberry9.github.io/the-wrong-memory/Appendix_02.html D safe subset: the programmer must stay within a subset whose rules maintain the invariant. A stronger design: the language's semantics make the invariant unavoidable, except at explicitly identified escape boundaries. 'Safe by default' is not the same thing as 'safety is a language property.' C++ made the mistake of trying to have a 'safe subset' without making the subset's invariants fundamental to the language itself. Did D make the same mistake?It's primarly about memory safety in C, but D gets a mention in the Appendix I. But it raises the question: why isn't safe not the default in D? https://strawberry9.github.io/the-wrong-memoryMemory safety is best when it is intentionally, forcing it everywhere by default usually achieves the opposite of its goal by adding unnecessary friction D shouldn't try to replicate Rust, its real strength is ipragmatism, giving the flexibility to opt into safety where it matters without imposing it where it doesn't
Aug 18
On Tuesday, 18 August 2026 at 16:48:07 UTC, Kapendev wrote:[...] Slices are part of the language, for example.indeed. Now I realize that a part of this topic was too focused on ` safe`. Actually D without ` safe` brings safety already. Temporal safety with the GC and spacial safety with bounds checks.
Aug 19
On Wednesday, 19 August 2026 at 16:01:41 UTC, user1234 wrote:On Tuesday, 18 August 2026 at 16:48:07 UTC, Kapendev wrote:If you program in D's betterC subset as I do, then the story varies. Many of the 'characteristics that are analogous to C remain': https://blog.dlang.org/archive/2017/08/23/d-as-a-better-c/ D, even with its betterC subset certainly raises the bar over C - there is no doubt about that.But many of the issues raised in 'The Wrong Memory' still apply to that subset. https://strawberry9.github.io/the-wrong-memory/cover.html[...] Slices are part of the language, for example.indeed. Now I realize that a part of this topic was too focused on ` safe`. Actually D without ` safe` brings safety already. Temporal safety with the GC and spacial safety with bounds checks.
Aug 19
On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:It's primarly about memory safety in C, but D gets a mention in the Appendix I. But it raises the question: why isn't safe not the default in D?There actually was [a decision to make it the default, which was soon reverted](https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1028.md). Pretty much everybody was (and probably is, over an edition switch since we now have those) willing to go on with that. There's an unfortunate gotcha though, which ended up killing the DIP. Consider a module naively declaring some C or C++ functions, something like ```D module foo; extern(C) void* malloc(size_t); extern(C) void free(void*); ``` is now fine but with a default ` safe` will now introduce unsafe functions usable from ` safe` code. Almost everyone considered this unacceptable. However, simply specifying that external functions with a foreign language linkage would remain ` system` by default has another problem: the maintainer of the prototypes can be tempted to simply add ` safe:` or ` trusted:` to the top of the declarations to get the now-` safe` client code to compile again with minimal effort, and once again we have unsafe functions callable from ` safe` code. Walter considered this unacceptable. I wonder though if the situation has now changed though. When the DIP was written, there would have been surge of compilation errors from previously ` system` code becoming ` safe` overnight, and therefore pressure to cut corners with the measures to get code compiling again. But today, it wouldn't be the case since the new default would only apply to code under a new edition. Existing code would stay at older editions until reannotated to conform, so there would be no breakage to deal with. Walter, if you happen to read this how does this sound?
Aug 17
On 8/17/2026 10:53 AM, Dukc wrote:Walter, if you happen to read this how does this sound?I think we agreed that going "safer" by default was a good candidate for an edition.
Aug 17
On Monday, 17 August 2026 at 20:30:21 UTC, Walter Bright wrote:On 8/17/2026 10:53 AM, Dukc wrote:Where? Saw no mention of that. When the switch was discussed last December when you had added it, I'd say the reception was mixed. It could well be better than nothing if a full safe by default isn't an option. But my point was, maybe it is an option after all? You rejected the amendment the community demanded to DIP1028, because you felt that the large amounts of code becoming ` safe` at once and stopping compiling would have people to greenwash their interfaces to C functions as falsely safe. But back then we didn't have editions. Since we now do, it means the code is not going to break until people update their edition specifications in their code. So there's no hurry to get all those C functions ` safe` or ` trusted`, and thus no pressure to cut corners and greenwash them. Don't you feel we could now have a real safe by default in a shiny new edition instead of just a compromise?Walter, if you happen to read this how does this sound?I think we agreed that going "safer" by default was a good candidate for an edition.
Aug 19
On Monday, 17 August 2026 at 17:53:22 UTC, Dukc wrote:```D module foo; extern(C) void* malloc(size_t); extern(C) void free(void*); ``` is now fine but with a default ` safe` will now introduce unsafe functions usable from ` safe` code. Almost everyone considered this unacceptable. However, simply specifying that external functions with a foreign language linkage would remain ` system` by default has another problem:The solution is to make declaring a foreign linkage function ` safe` a compile-time error.the maintainer of the prototypes can be tempted to simply add ` safe:` or ` trusted:` to the top of the declarations to get the now-` safe` client code to compile again with minimal effort, and once again we have unsafe functions callable from ` safe` code. Walter considered this unacceptable.In a way it's good if a module is marked ` trusted:`, because that is a massive red flag to a reviewer of the code. OTOH ` safe:` is a lie if it applies to foreign linkage prototypes, because the D compiler cannot check them for memory-safety. D prototypes can be ` safe` as they have different linkage from ` system` functions.
Aug 17