www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D not considered memory safe

reply Brian Callahan <bcallah openbsd.org> writes:
...at least according to Bleeping Computer: 
https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/

"Memory-unsafe languages are those that do not provide built-in 
memory management mechanisms, burdening the developer with this 
responsibility and increasing the likelihood of errors. Examples 
of such cases are C, C++, Objective-C, Assembly, Cython, and D."
Jul 01
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 1 July 2024 at 13:40:41 UTC, Brian Callahan wrote:

 ...at least according to Bleeping Computer: 
 https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/

 "Memory-unsafe languages are those that do not provide built-in 
 memory management mechanisms, burdening the developer with this 
 responsibility and increasing the likelihood of errors. 
 Examples of such cases are C, C++, Objective-C, Assembly, 
 Cython, and D."


Propaganda article, they don't even mention Ada...
Jul 01
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Monday, 1 July 2024 at 13:40:41 UTC, Brian Callahan wrote:

 ...at least according to Bleeping Computer: 
 https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/

 "Memory-unsafe languages are those that do not provide built-in 
 memory management mechanisms, burdening the developer with this 
 responsibility and increasing the likelihood of errors. 
 Examples of such cases are C, C++, Objective-C, Assembly, 
 Cython, and D."


It looks like that list comes directly from the CISA report. And 
it’s not exactly wrong, D is not safe by default. For example 
they don’t consider rust to be an unsafe language simply because 
you can use unsafe blocks.

D would I think need to be safe by default and use dip1000 by 
default to be appropriately labeled safe.

I’m still trying to find out more about the criteria, because I 
don’t think it discusses how languages were put into these 
buckets of safe and unsafe.

-Steve
Jul 01
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/1/24 16:00, Steven Schveighoffer wrote:

 
 D would I think need to be safe by default and use dip1000 by default to 
 be appropriately labeled safe.
 
 I’m still trying to find out more about the criteria, because I don’t 
 think it discusses how languages were put into these buckets of safe and 
 unsafe.


Well, it cannot be the criteria cited in the OP:

 "Memory-unsafe languages are those that do not provide built-in memory
management mechanisms, burdening the developer with this responsibility and
increasing the likelihood of errors. Examples of such cases are C, C++,
Objective-C, Assembly, Cython, and D."


This is plainly incorrect. D has a GC, which is a built-in memory 
management mechanism.

Safety is not about what you can do, but about what errors you can't 
make. I guess what's maybe holding D back a bit is the tendency of D 
programmers to opt for malloc-backed data structures with unestricted 
`ref` access to elements. DIP1000 can hep but is a bit restricted.

But ultimately technical concerns are probably secondary, and it is 
mostly about marketing (and what kind of programmers that attracts for 
building the ecosystem):


 With the D Programming Language, write fast, read fast, and run fast.
 
 Fast code, fast.


Compare this to:


 A language empowering everyone to build reliable and efficient software.
 Reliability: Rust’s rich type system and ownership model guarantee
memory-safety and thread-safety — enabling you to eliminate many classes of
bugs at compile-time. 


Technically those guarantees are not fully reliable, but the main 
webpage says they are right in your face, that's perhaps necessary, or 
even sufficient.
Jul 02
parent Monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 2 July 2024 at 21:57:14 UTC, Timon Gehr wrote:

 This is plainly incorrect. D has a GC, which is a built-in 
 memory management mechanism.


Your thinking logically and not with hype and trends, and that's 
clearly not what the cia is about, now bad open source dev learn 
rust
Jul 02
prev sibling next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 02/07/2024 1:40 AM, Brian Callahan wrote:

 ...at least according to Bleeping Computer: 
 https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/
 
 "Memory-unsafe languages are those that do not provide built-in memory 
 management mechanisms, burdening the developer with this responsibility 
 and increasing the likelihood of errors. Examples of such cases are C, 
 C++, Objective-C, Assembly, Cython, and D."


They are indeed correct that D isn't memory safe however they are 
conflating multiple things here.

D has no solution to temporal safety which is what Rust has via its 
borrow checker.

For D the first step to temporal safety would be owner escape analysis 
which I am currently working on. However it is expensive as to do it 
properly means you need a DFA.

We do have a GC which does means we have memory safety in terms of 
lifetimes or non-owning data structures. Nor does this help with the stack.

Data races on the other hand is temporal safety + atomics + locks + 
immutable. We're missing what is needed to pull all that together right 
now as one feature.
Jul 01
prev sibling next sibling parent reply Monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 1 July 2024 at 13:40:41 UTC, Brian Callahan wrote:

 ...at least according to Bleeping Computer: 
 https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/

 "Memory-unsafe languages are those that do not provide built-in 
 memory management mechanisms, burdening the developer with this 
 responsibility and increasing the likelihood of errors. 
 Examples of such cases are C, C++, Objective-C, Assembly, 
 Cython, and D."


Yay..... The cia is going to push rust on unpaid devs what could 
go wrong
Jul 01
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Jul 01, 2024 at 02:51:12PM +0000, Monkyyy via Digitalmars-d wrote:

 On Monday, 1 July 2024 at 13:40:41 UTC, Brian Callahan wrote:

 ...at least according to Bleeping Computer:
 https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/
 
 "Memory-unsafe languages are those that do not provide built-in
 memory management mechanisms, burdening the developer with this
 responsibility and increasing the likelihood of errors. Examples of
 such cases are C, C++, Objective-C, Assembly, Cython, and D."


 
 Yay..... The cia is going to push rust on unpaid devs what could go wrong


https://xkcd.com/2347/


T

-- 
No! I'm not in denial!
Jul 01
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/1/2024 6:40 AM, Brian Callahan wrote:

 ...at least according to Bleeping Computer: 
 https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/
 
 "Memory-unsafe languages are those that do not provide built-in memory 
 management mechanisms, burdening the developer with this responsibility and 
 increasing the likelihood of errors. Examples of such cases are C, C++, 
 Objective-C, Assembly, Cython, and D."


Now they're complaining that D does not have a gc!
Jul 02
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 2 July 2024 at 23:33:22 UTC, Walter Bright wrote:

 On 7/1/2024 6:40 AM, Brian Callahan wrote:

 ...at least according to Bleeping Computer: 
 https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisa-most-critical-open-source-projects-not-using-memory-safe-code/amp/
 
 "Memory-unsafe languages are those that do not provide 
 built-in memory management mechanisms, burdening the developer 
 with this responsibility and increasing the likelihood of 
 errors. Examples of such cases are C, C++, Objective-C, 
 Assembly, Cython, and D."


 Now they're complaining that D does not have a gc!


Well, the article is wrong that having a GC prevents all memory 
safety problems.

What causes all the problems (mostly) is the "built-in memory 
management" of the stack, and critically, returning references to 
stack data that will outlive the stack frame. Having a GC isn't 
enough, every single memory allocation scheme must also be safe 
to have a safe language.

But to be fair, I don't think the linked report actually 
discusses the definition of memory safe languages. It's just 
bleeping computer that adds this (bad) explanation. The CISA 
report does specifically list D as a memory unsafe language, 
which I think is a bit harsh.

What I would say with D is that it is *much easier* to be memory 
safe, and the compiler provides tools to help with this.

-Steve
Jul 02
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/2/2024 9:30 PM, Steven Schveighoffer wrote:

 Well, the article is wrong that having a GC prevents all memory safety
problems.
 
 What causes all the problems (mostly) is the "built-in memory management" of
the 
 stack, and critically, returning references to stack data that will outlive
the 
 stack frame.


The compiler protects against that. Give it a try!



 Having a GC isn't enough, every single memory allocation scheme 
 must also be safe to have a safe language.


To be memory safe, you'd have to use the GC instead of malloc/free. Using the 
stack is ok.



 What I would say with D is that it is *much easier* to be memory safe, and the 
 compiler provides tools to help with this.


D does much better than that if one sticks with  safe code and the GC.
Jul 03
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 3 July 2024 at 18:03:52 UTC, Walter Bright wrote:

 On 7/2/2024 9:30 PM, Steven Schveighoffer wrote:

 Well, the article is wrong that having a GC prevents all 
 memory safety problems.
 
 What causes all the problems (mostly) is the "built-in memory 
 management" of the stack, and critically, returning references 
 to stack data that will outlive the stack frame.


 The compiler protects against that. Give it a try!


Not sure if you know this, but I've used D before.


 Having a GC isn't enough, every single memory allocation 
 scheme must also be safe to have a safe language.


 To be memory safe, you'd have to use the GC instead of 
 malloc/free. Using the stack is ok.


```d
ref int bar(ref int x) => x;

ref int foo()
{
    int i = 0;
    return bar(i);
}
```

Compiles, even with dip1000.


 What I would say with D is that it is *much easier* to be 
 memory safe, and the compiler provides tools to help with this.


 D does much better than that if one sticks with  safe code and 
 the GC.


Yes, it should be the default IMO. If nothing, this should help 
get it off these lists of "unsafe languages", which I agree is 
important.

-Steve
Jul 03
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 04/07/2024 1:52 PM, Steven Schveighoffer wrote:

 |ref int bar(ref int x) => x; ref int foo() { int i = 0; return bar(i); } |
 
 Compiles, even with dip1000.


``-preview=dip1000``

```d
 safe:

ref int bar(ref int x) => x;

ref int foo()
{
     int i = 0;
     return bar(i);
}

void main() {
     int* v = &foo();
}
```

```
<source>(3): Error: returning `x` escapes a reference to parameter `x`
<source>(3):        perhaps annotate the parameter with `return`
```

And when annotated:

```
<source>(8): Error: returning `bar(i)` escapes a reference to local 
variable `i`
```
Jul 03
next sibling parent reply Sebastian Nibisz <snibisz gmail.com> writes:
On Thursday, 4 July 2024 at 02:00:52 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 ``-preview=dip1000``

 ```d
  safe:

 ref int bar(ref int x) => x;

 ref int foo()
 {
     int i = 0;
     return bar(i);
 }

 void main() {
     int* v = &foo();
 }
 ```

 ```
 <source>(3): Error: returning `x` escapes a reference to 
 parameter `x`
 <source>(3):        perhaps annotate the parameter with `return`
 ```

 And when annotated:

 ```
 <source>(8): Error: returning `bar(i)` escapes a reference to 
 local variable `i`
 ```


An unsafe programming language is one that allows to write unsafe 
code by default. If D is to be more safe, then  safe should be 
the default and  unsafe optional.
Jul 04
parent reply Lance Bachmeier <no spam.net> writes:
On Thursday, 4 July 2024 at 07:11:13 UTC, Sebastian Nibisz wrote:

 On Thursday, 4 July 2024 at 02:00:52 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 ``-preview=dip1000``

 ```d
  safe:

 ref int bar(ref int x) => x;

 ref int foo()
 {
     int i = 0;
     return bar(i);
 }

 void main() {
     int* v = &foo();
 }
 ```

 ```
 <source>(3): Error: returning `x` escapes a reference to 
 parameter `x`
 <source>(3):        perhaps annotate the parameter with 
 `return`
 ```

 And when annotated:

 ```
 <source>(8): Error: returning `bar(i)` escapes a reference to 
 local variable `i`
 ```


 An unsafe programming language is one that allows to write 
 unsafe code by default. If D is to be more safe, then  safe 
 should be the default and  unsafe optional.


Safety isn't important to anyone that can't be troubled to write 
`-preview=dip1000`.
Jul 04
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, July 4, 2024 10:11:56 AM MDT Lance Bachmeier via Digitalmars-d 
wrote:

 On Thursday, 4 July 2024 at 07:11:13 UTC, Sebastian Nibisz wrote:

 An unsafe programming language is one that allows to write
 unsafe code by default. If D is to be more safe, then  safe
 should be the default and  unsafe optional.


 Safety isn't important to anyone that can't be troubled to write
 `-preview=dip1000`.


You can write  safe code quite easily as long as you're not doing stuff like
taking the address of the stack, and you can verify the safety of that
yourself and mark the code as  trusted so long as you're not doing anything
crazy with it.

Personally, I won't touch DIP 1000 with a ten foot pole, because it's way
too complicated. And using the GC for memory allocations makes it
unnecessary in general.

Either way, it's certainly not the case that  safe by default is required
for memory safety at all. It might make it easier, because you have to mark
less with  safe explicitly, but changing the default doesn't inherently make
programs more memory safe. It might help the marketing aspect of things, but
from a technical perspective, D is just as memory safe either way. And for
those who want the pain, -preview=dip1000 does provide additional checks.

- Jonathan M Davis
Jul 04
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 4 July 2024 at 02:00:52 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 04/07/2024 1:52 PM, Steven Schveighoffer wrote:

 |ref int bar(ref int x) => x; ref int foo() { int i = 0; 
 return bar(i); } |
 
 Compiles, even with dip1000.


 ``-preview=dip1000``

 ```d
  safe:

 ref int bar(ref int x) => x;

 ref int foo()
 {
     int i = 0;
     return bar(i);
 }

 void main() {
     int* v = &foo();
 }
 ```

 ```
 <source>(3): Error: returning `x` escapes a reference to 
 parameter `x`
 <source>(3):        perhaps annotate the parameter with `return`
 ```

 And when annotated:

 ```
 <source>(8): Error: returning `bar(i)` escapes a reference to 
 local variable `i`
 ```


I'm aware. Not writing ` safe:` at the top was intentional.

-Steve
Jul 04
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 4 July 2024 at 01:52:23 UTC, Steven Schveighoffer 
wrote:

 
 Yes, it should be the default IMO. If nothing, this should help 
 get it off these lists of "unsafe languages", which I agree is 
 important.


Why?

My read of the situation is an its an informal jobs program, d is 
to good to dig ditches then refill them again, rust isnt.
Jul 03
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/3/2024 6:52 PM, Steven Schveighoffer wrote:

 ```d
 ref int bar(ref int x) => x;
 
 ref int foo()
 {
     int i = 0;
     return bar(i);
 }
 ```
 
 Compiles, even with dip1000.


```
 safe:  // <=== I added this line

ref int bar(ref int x) => x;

ref int foo()
{
     int i = 0;
     return bar(i);
}
```

fails with:

```
test.d(3): Error: returning `x` escapes a reference to parameter `x`
test.d(3):        perhaps annotate the parameter with `return`
```

when compiled with -preview=dip1000
Jul 05
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Friday, 5 July 2024 at 16:41:01 UTC, Walter Bright wrote:

  safe:  // <=== I added this line


Yes, I'm aware. I purposely did not apply ` safe`. D is not a 
memory safe language, you have to request it. It is not good 
enough to say "Using the stack is ok" as you did 
[here](https://forum.dlang.org/post/v643q1$230o$1 digitalmars.com). In fact, D
is less safe with -dip1000 on system code, as it will hoist some allocations to
the stack, even when requested with `new`.

Compare this to Rust which is safe unless you ask for unsafe 
blocks.

-Steve
Jul 05
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/5/2024 12:42 PM, Steven Schveighoffer wrote:

 Yes, I'm aware. I purposely did not apply ` safe`. D is not a memory safe 
 language, you have to request it.


D is memory safe if you type in "safe:" and use the gc.

https://dlang.org/spec/memory-safe-d.html
Jul 05
parent reply Sebastian Nibisz <snibisz gmail.com> writes:
On Saturday, 6 July 2024 at 00:21:32 UTC, Walter Bright wrote:

 On 7/5/2024 12:42 PM, Steven Schveighoffer wrote:

 Yes, I'm aware. I purposely did not apply ` safe`. D is not a 
 memory safe language, you have to request it.


 D is memory safe if you type in "safe:" and use the gc.

 https://dlang.org/spec/memory-safe-d.html


Seriously? Any language is safe in this case, you just need to 
write safe code.
Jul 06
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 6 July 2024 at 11:07:32 UTC, Sebastian Nibisz wrote:

 On Saturday, 6 July 2024 at 00:21:32 UTC, Walter Bright wrote:

 On 7/5/2024 12:42 PM, Steven Schveighoffer wrote:

 Yes, I'm aware. I purposely did not apply ` safe`. D is not a 
 memory safe language, you have to request it.


 D is memory safe if you type in "safe:" and use the gc.

 https://dlang.org/spec/memory-safe-d.html


 Seriously? Any language is safe in this case, you just need to 
 write safe code.


To say something "doesn't have safety tuned on by default" vs 
"something is unsafe" communicates two different meanings.

 From another angle, would you choose "less freedom but more 
security" or "more freedom but less security"? You can't have 
both.

D is a very safe non-strict modern language. It allows you to 
shoot yourself in the foot or gives you more freedom and control. 
D however does a much better job at preventing you from shooting 
your foot even without strict safety turned on by default.

This argument in my opinion is more about strict vs non-strict 
(by default) because you can have strict safety by default in D 
of you want it.
Jul 06
next sibling parent reply Sebastian Nibisz <snibisz gmail.com> writes:
On Saturday, 6 July 2024 at 14:56:27 UTC, aberba wrote:

 To say something "doesn't have safety tuned on by default" vs 
 "something is unsafe" communicates two different meanings.


Is a car that has airbags deactivated by default before each 
drive safe?
Jul 06
next sibling parent reply Lance Bachmeier <no spam.net> writes:
On Saturday, 6 July 2024 at 22:48:32 UTC, Sebastian Nibisz wrote:

 On Saturday, 6 July 2024 at 14:56:27 UTC, aberba wrote:

 To say something "doesn't have safety tuned on by default" vs 
 "something is unsafe" communicates two different meanings.


 Is a car that has airbags deactivated by default before each 
 drive safe?


Typing ` safe:` is not a big deal. Turning on safe automatically 
requires anyone working with C code or otherwise writing unsafe 
code to turn it off. To use the airbag analogy, there are people 
for whom airbags are unsafe so they are disabled. Whether that is 
the right choice depends on the costs and benefits of doing so. 
What you can't say is that air bags should always be turned on or 
off in every car because that's safer for you.
Jul 06
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Saturday, 6 July 2024 at 23:14:00 UTC, Lance Bachmeier wrote:

 Typing ` safe:` is not a big deal.


Typing  safe: is also incorrect. You will cause your templates to 
fail to compile.

-Steve
Jul 06
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/6/2024 9:10 PM, Steven Schveighoffer wrote:

 Typing  safe: is also incorrect. You will cause your templates to fail to
compile.


??
Jul 08
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/9/24 01:21, Walter Bright wrote:

 On 7/6/2024 9:10 PM, Steven Schveighoffer wrote:

 Typing  safe: is also incorrect. You will cause your templates to fail 
 to compile.


 
 ??
 


Templates are inferred by default:

```d
auto call(alias a)(){ a(); }

 safe void foo(){}
 system void bar(){}

 safe void fun(){ call!fun(); }
 system void gun(){ call!bar(); }
```

If you annotate `call` with ` safe`, some of those calls will no longer 
work. It removes functionality even though it was already compatible 
with ` safe` code.

` safe:` will put ` safe` on all your function templates, which will 
make them not work in ` system` contexts even if they worked before.

The issue is that it applies the attribute, when what is needed is a way 
to change the default attribute.
Jul 08
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2024 5:37 PM, Timon Gehr wrote:

 Templates are inferred by default:


Thanks for the explanation. It's just  safe templates cannot call  system
functions.

Essentially, if you have mixed safe functions and system functions,
unannotated, 
and then you apply Shazaam! Make it all  safe! then yes, you're going to have
to 
deal with the code that cannot safe.

I don't see this as a problem. It's the whole point.
Jul 10
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/10/24 23:47, Walter Bright wrote:

 On 7/8/2024 5:37 PM, Timon Gehr wrote:

 Templates are inferred by default:


 
 Thanks for the explanation. It's just  safe templates cannot call 
  system functions.
 ...


No. That's not it. A template that calls a system function is just not 
` safe`, and is inferred that way.

The issue is that there is no way to say " safe by default, keep 
inference enabled", you can only say " safe, disable inference".

Therefore, you are either stuck with ` system` by default or you are 
left with no ` safe` inference.


 Essentially, if you have mixed safe functions and system functions, 
 unannotated, and then you apply Shazaam! Make it all  safe! then yes, 
 you're going to have to deal with the code that cannot safe.
 
 I don't see this as a problem. It's the whole point.


That's the point of writing ` safe:`. This is however not what is needed 
in this context.

The problem is not with ` safe:`, it is that there is a missing feature.
Jul 10
parent reply Walter Bright <newshound2 digitalmars.com> writes:
The missing feature is there:

```
 safe {
    .. templates that must be safe ..
}

.. templates that infer safe ..
```
Jul 10
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 11/07/2024 2:31 PM, Walter Bright wrote:

 The missing feature is there:
 
 ```
  safe {
     .. templates that must be safe ..
 }
 
 .. templates that infer safe ..
 ```


The point is, once  safe is the default, that capability goes away 
without  infer.
Jul 10
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2024 7:33 PM, Richard (Rikki) Andrew Cattermole wrote:

 The point is, once  safe is the default, that capability goes away without
 infer.


I understand that.

First,  system code should be a very small part of a program. If complex things 
are being done with layers of templates in  system code, I propose that is a 
badly designed program.

Second, just declare them  trusted until one gets around to a proper
refactoring.

In fact, I've been doing just that. Adding  safe: at the top, and then 
everything that fails to compile gets marked  trusted. Eventually, refactor the 
code as time permits.

No need for Yet Another Attribute.
Jul 10
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 11/07/2024 5:59 PM, Walter Bright wrote:

 On 7/10/2024 7:33 PM, Richard (Rikki) Andrew Cattermole wrote:

 The point is, once  safe is the default, that capability goes away 
 without  infer.


 
 I understand that.
 
 First,  system code should be a very small part of a program. If complex 
 things are being done with layers of templates in  system code, I 
 propose that is a badly designed program.
 
 Second, just declare them  trusted until one gets around to a proper 
 refactoring.
 
 In fact, I've been doing just that. Adding  safe: at the top, and then 
 everything that fails to compile gets marked  trusted. Eventually, 
 refactor the code as time permits.
 
 No need for Yet Another Attribute.


Yeah I get that, but that is a major problem for things like std.algorithm.

There will be situations without a migration path forward.
Jul 10
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2024 11:31 PM, Richard (Rikki) Andrew Cattermole wrote:

 Yeah I get that, but that is a major problem for things like std.algorithm.
 
 There will be situations without a migration path forward.


Pass  trusted arguments to the templates.

The truth is about every piece of existing code not already annotated is going 
to fail to compile with safe-by-default. That's been my experience, at least.

The migration path is to mark the stuff with  trusted. You can see that in the 
dmd source code.
Jul 11
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Thursday, 11 July 2024 at 16:16:25 UTC, Walter Bright wrote:

 On 7/10/2024 11:31 PM, Richard (Rikki) Andrew Cattermole wrote:

 Yeah I get that, but that is a major problem for things like 
 std.algorithm.
 
 There will be situations without a migration path forward.


 Pass  trusted arguments to the templates.

 The truth is about every piece of existing code not already 
 annotated is going to fail to compile with safe-by-default. 
 That's been my experience, at least.

 The migration path is to mark the stuff with  trusted. You can 
 see that in the dmd source code.


My bet is annotating things ` trusted` on a large basis is going 
to end up an eternal makeshift.

My solution is you annotate modules. If you’re a library writer, 
yes, you’re still out of luck. But as an application writer, if 
you write `default  safe module m;` the module’s default is 
` safe` now. Defaults don’t touch templates and other inferred 
functions, but they do (meaningfully) touch interfaces and 
higher-order functions. If you’re developing an application and 
some interface or higher-order function doesn’t work for you 
after adding some annotation, well, it’s your code. Change it to 
your needs.

For existing libraries that aren’t annotated, the situation is 
worse as users may rely on them being ` system`, e.g. because you 
(logically) can’t implement a ` safe` interface method with a 
` system` function. For a higher-order function in a library 
without attributes, if the function is relatively-safe (i.e. 
calls with ` safe` delegate are safe), you can write a ` trusted` 
wrapper that just casts the original:

```d
import noattrib;
alias hof = noattrib.hof;
auto hof(void delegate()  safe callback)  trusted => 
noattrib.hof(callback);
```
Jul 22
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/22/2024 7:14 AM, Quirin Schroll wrote:

 My bet is annotating things ` trusted` on a large basis is going to end up an 
 eternal makeshift.


Perhaps. But it is still up to the user to edit their code to make it  safe,
one 
way or another.
Jul 22
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 11 July 2024 at 05:59:08 UTC, Walter Bright wrote:


 Second, just declare them  trusted until one gets around to a 
 proper refactoring.

 In fact, I've been doing just that. Adding  safe: at the top, 
 and then everything that fails to compile gets marked  trusted. 
 Eventually, refactor the code as time permits.

 No need for Yet Another Attribute.


So, the solution is just turn your program into a gigantic facade 
of  safe, until you have time to refactor it as really  safe?

Meh ...
Jul 11
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2024 12:53 AM, Paolo Invernizzi wrote:

 So, the solution is just turn your program into a gigantic facade of  safe, 
 until you have time to refactor it as really  safe?


Yes.

Let's say you have a spaghetti flow graph of a pile of functions calling each 
other. Some of them are not safe, and so the functions that call the functions 
that call the functions are not safe, in recursive cycles (like the compile 
implementation!). How do you go about making the whole thing safe? It's most 
practical to do things incrementally - so mark everything trusted, and then, 
starting with the leaves, rework them to make them safe.

Trying to redo it all in one go is only going to lead to frustration.
Jul 11
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 7/11/24 18:23, Walter Bright wrote:

 mark everything trusted


:(

You can't mark a function  trusted if it does not have a  safe interface.
Jul 11
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/11/24 07:59, Walter Bright wrote:

 On 7/10/2024 7:33 PM, Richard (Rikki) Andrew Cattermole wrote:

 The point is, once  safe is the default, that capability goes away 
 without  infer.


 
 I understand that.
 
 First,  system code should be a very small part of a program. If complex 
 things are being done with layers of templates in  system code, I 
 propose that is a badly designed program.
 ...


So? A template library should still work with ` system` lambdas.


 Second, just declare them  trusted until one gets around to a proper 
 refactoring.
 
 In fact, I've been doing just that. Adding  safe: at the top, and then 
 everything that fails to compile gets marked  trusted. Eventually, 
 refactor the code as time permits.
 
 No need for Yet Another Attribute.


If even the main language designer advocates for randomly sprinkling 
` trusted` to shut up the compiler, there is no hope for memory safe D.
Jul 11
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2024 3:18 AM, Timon Gehr wrote:

 If even the main language designer advocates for randomly sprinkling
` trusted` 
 to shut up the compiler, there is no hope for memory safe D.


The only way to do a conversion of a large program is to mark them all  trusted 
and then fix the functions one by one. The remaining  trusted annotations are 
the TODO list.

If there's another practical way, I'm not aware of it.
Jul 15
parent Dukc <ajieskola gmail.com> writes:
Walter Bright kirjoitti 15.7.2024 klo 21.20:

 On 7/11/2024 3:18 AM, Timon Gehr wrote:

 If even the main language designer advocates for randomly sprinkling 
 ` trusted` to shut up the compiler, there is no hope for memory safe D.


 
 The only way to do a conversion of a large program is to mark them all 
  trusted and then fix the functions one by one. The remaining  trusted 
 annotations are the TODO list.
 
 If there's another practical way, I'm not aware of it.


1. Start by doing just what you did: mark something ` safe` that should 
be ` safe` and see what error messages pop up.

2. When the compiler complains you're calling a ` system` function, stop 
and think. If the function you're trying to call is supposed to have a 
safe API, then fine, go and mark it as ` trusted` and add it to todo 
list. But if you are, for instance, calling anything that takes a C 
string as an argument, please don't schlepp ` trusted` on that - that 
would be marking an unsafe API  safe. Use the trusted lambda trick instead.

3. If you had to add trusted lambdas and it annoys you, remove them when 
you're done and instead mark the whole function you were working on as 
` trusted`.
Jul 16
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2024 7:31 PM, Walter Bright wrote:

 The missing feature is there:
 
 ```
  safe {
     .. templates that must be safe ..
 }
 
 .. templates that infer safe ..
 ```


I might also add that it is good practice to put your unsafe code in another 
module, as well as code that may be inferred as unsafe.

In any case, we can keep adding more and more features to the language that add 
very little. But it's not going to go well, and nobody is going to read the
1000 
page specification. C and C++ have both gone down that path.
Jul 10
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/11/24 04:36, Walter Bright wrote:

 On 7/10/2024 7:31 PM, Walter Bright wrote:

 The missing feature is there:

 ```
  safe {
     .. templates that must be safe ..
 }

 .. templates that infer safe ..
 ```


 
 I might also add that it is good practice to put your unsafe code in 
 another module, as well as code that may be inferred as unsafe.
 
 In any case, we can keep adding more and more features to the language 
 that add very little. But it's not going to go well, and nobody is going 
 to read the 1000 page specification. C and C++ have both gone down that 
 path.
 
 


The simple point remains that Steven is absolutely correct that putting 
` safe:` does not work.
Jul 11
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2024 3:20 AM, Timon Gehr wrote:

 The simple point remains that Steven is absolutely correct that putting
` safe:` 
 does not work.


True, when the code is not  safe and needs fixin'.
Jul 15
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, July 15, 2024 12:21:24 PM MDT Walter Bright via Digitalmars-d 
wrote:

 On 7/11/2024 3:20 AM, Timon Gehr wrote:

 The simple point remains that Steven is absolutely correct that putting
 ` safe:` does not work.


 True, when the code is not  safe and needs fixin'.


It is the case more frequently than not that you do not want to mark
templated functions with  safe, and there is nothing about that that needs
fixing.

Most templated functions should be designed in a way that they work with
either  safe or  system depending on the template arguments, because you're
unnecessarily restricting the types or functions that can be used with the
template otherwise. Ideally, the templated function will be written in a way
that it will be  safe if all of the functions it's calling are  safe but not
require that any of them be  safe. Range-based code is a prime example of
this, because some ranges are  safe and some aren't, but code like
std.algorithm needs to work with them either way. If that templated code is
written properly, it will then be  safe if the range can be  safe, but if it
actually required  safe, then it wouldn't work with ranges that weren't
 safe. As such, for the majority of templated code, using  safe: is a
disaster and does not indicate that _anything_ needs fixing. Inference is
what's needed for the vast majority of templates.

Now, if you're writing a template that works on a specific subset of known
types (e.g. all integer types), then it becomes possible to use  safe
explicitly, because you know that what you're doing can be  safe for all of
the types that the templated function can be instantiated with, and it could
be considered a bug if the code didn't work with  safe:, but for many
templates, you need  safe to be inferred, and using  safe: causes nothing
but trouble.

In most cases, slapping : at the top of a module with any attribute causes
issues. It can even cause problems with stuff like public, since that can
easily result in a situation where you accidentally make imports public. In
general, : should be used with great caution with regards to attributes, and
in many cases, IMHO, it borders on being a code smell given how error-prone
it can be. It also becomes a problem with maintenance and code reviews,
because it's often not obvious that a particular attribute is in effect in a
section of the file when it was applied using :. So, using  safe: really is
not a solution for much of anything. It _can_ work in some cases, but I'd
strongly advise against it in general, because it will cause problems.

- Jonathan M Davis
Jul 17
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Mark the arguments to a template as  trusted if they are not safe, and the 
template will then be safe.

The real issue here is too much unsafe code. There isn't a way to fix that 
without rolling up one's sleeves and going after it hammer and tong.
Jul 22
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/22/24 18:47, Walter Bright wrote:

 Mark the arguments to a template as  trusted if they are not safe, and 
 the template will then be safe.
 ...


No. It will be  safe, but possibly not memory safe. Again, this is pure 
safewashing. What is even the point of this exercise?
Jul 22
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/22/2024 11:51 AM, Timon Gehr wrote:

 What is even the point of this exercise?


To provide a migration path for people who want their code to be safe.

Can't stop people from misusing  trusted.
Jul 24
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 7/25/24 03:49, Walter Bright wrote:

 On 7/22/2024 11:51 AM, Timon Gehr wrote:

 What is even the point of this exercise?


 
 To provide a migration path for people who want their code to be safe.
 ...


You mean ` safe`. It will not be safe.


 Can't stop people from misusing  trusted.


In this thread, you have been actively encouraging people to misuse 
` trusted`.
Jul 25
prev sibling next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 6 July 2024 at 22:48:32 UTC, Sebastian Nibisz wrote:

 On Saturday, 6 July 2024 at 14:56:27 UTC, aberba wrote:

 To say something "doesn't have safety tuned on by default" vs 
 "something is unsafe" communicates two different meanings.


 Is a car that has airbags deactivated by default before each 
 drive safe?


Is a car that has seatbelts unhooked by default safe? Is a car 
that can active the engine without annotating which seats are 
being sat in safe?
Jul 06
parent reply Sebastian Nibisz <snibisz gmail.com> writes:
On Sunday, 7 July 2024 at 00:48:49 UTC, monkyyy wrote:

 On Saturday, 6 July 2024 at 22:48:32 UTC, Sebastian Nibisz

 Is a car that has airbags deactivated by default before each 
 drive safe?


 Is a car that has seatbelts unhooked by default safe? Is a car 
 that can active the engine without annotating which seats are 
 being sat in safe?


Cars warn when you don't wear your seat belt. The newest cars 
won't let you drive.
Jul 07
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 7 July 2024 at 09:47:51 UTC, Sebastian Nibisz wrote:

 On Sunday, 7 July 2024 at 00:48:49 UTC, monkyyy wrote:

 On Saturday, 6 July 2024 at 22:48:32 UTC, Sebastian Nibisz

 Is a car that has airbags deactivated by default before each 
 drive safe?


 Is a car that has seatbelts unhooked by default safe? Is a car 
 that can active the engine without annotating which seats are 
 being sat in safe?


 Cars warn when you don't wear your seat belt. The newest cars 
 won't let you drive.


Out of curiosity, which cars won't let you drive if you don't 
have the seat belt on?

That sounds like a really bad (and potentially dangerous) design.
Jul 11
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Saturday, 6 July 2024 at 22:48:32 UTC, Sebastian Nibisz wrote:

 On Saturday, 6 July 2024 at 14:56:27 UTC, aberba wrote:

 To say something "doesn't have safety tuned on by default" vs 
 "something is unsafe" communicates two different meanings.


 Is a car that has airbags deactivated by default before each 
 drive safe?


This is not a good comparison. You could have come up with 
anything else unrelated besides this to still make it seem like 
you have a point.

D has array bounds check and many others turned on by default. 
Current D chose to give Dev more freedom and the tools to turn on 
strict checks when that's desired...as long as you're okay with 
the cons.

If rusts way of shoveling their strict ownership model in your 
throat was the overall best, many other system programming 
language after it would be doing same.
Jul 08
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/6/24 16:56, aberba wrote:

  From another angle, would you choose "less freedom but more security" 
 or "more freedom but less security"? You can't have both.


Arguably, security is a form of freedom.
Jul 08
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 8 July 2024 at 15:27:49 UTC, Timon Gehr wrote:

 On 7/6/24 16:56, aberba wrote:

  From another angle, would you choose "less freedom but more 
 security" or "more freedom but less security"? You can't have 
 both.


 Arguably, security is a form of freedom.


Maybe in some political theories, but on a computer? No

Binary and basically perfect data storage changes the 
fuzziness/analog required for those political theories.

Either the function has a throw in the code path or it doesnt; 
either a function throws on nan or treats it as a 0; for each 
type of error its either the compiler stops or it prints a 
warning people ignore.

When "safety is nessery for freedom" argument is made 
politically, at least they are referring to say freedom of 
movement is limited by the chance of muggers or something and 
theres at least tradeoffs to consider for humans following 
instructions poorly and large scale physical systems being 
inherently probabilistic.
Jul 08
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/8/24 18:16, monkyyy wrote:

 On Monday, 8 July 2024 at 15:27:49 UTC, Timon Gehr wrote:

 On 7/6/24 16:56, aberba wrote:

  From another angle, would you choose "less freedom but more 
 security" or "more freedom but less security"? You can't have both.


 Arguably, security is a form of freedom.


 
 Maybe in some political theories, but on a computer? No
 ...


The context here is programming a computer. I don't know why you jump to 
politics. It's also against the forum guidelines.

The simple fact is that if you program in a language without footguns, 
you are free to not worry about shooting your own foot. (Assuming you 
like having feet.)
Jul 08
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2024 4:18 PM, Timon Gehr wrote:

 The simple fact is that if you program in a language without footguns, you are 
 free to not worry about shooting your own foot. (Assuming you like having
feet.)


A "footgun" is just another word for "bug". There is no known way to craft a 
computer language to make bugs impossible.

Oh, perhaps there is a way - a programming language that doesn't allow you to
do 
anything.
Jul 10
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/10/24 23:50, Walter Bright wrote:

 On 7/8/2024 4:18 PM, Timon Gehr wrote:

 The simple fact is that if you program in a language without footguns, 
 you are free to not worry about shooting your own foot. (Assuming you 
 like having feet.)


 
 A "footgun" is just another word for "bug".


This is not true. A footgun in this context is something that encourages 
the creation of bugs. A "footgun" is another word for "error-prone design".


 There is no known way to 
 craft a computer language to make bugs impossible.
 
 Oh, perhaps there is a way - a programming language that doesn't allow 
 you to do anything.


There is a wide spectrum between the two extremes. You are here engaging 
in unproductive black and white thinking.

Again, just watch your own keynote from last year's DConf. All airplanes 
can crash, that does not mean all cockpit designs are equivalent.
Jul 10
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2024 5:19 PM, Timon Gehr wrote:

 On 7/10/24 23:50, Walter Bright wrote:

 On 7/8/2024 4:18 PM, Timon Gehr wrote:

 The simple fact is that if you program in a language without footguns, you 
 are free to not worry about shooting your own foot. (Assuming you like having 
 feet.)


 A "footgun" is just another word for "bug".


 
 This is not true. A footgun in this context is something that encourages the 
 creation of bugs. A "footgun" is another word for "error-prone design".


2's complement arithmetic? Floating point arithmetic? Operator precedence?

All of those are footguns. We live with them because attempts to avoid them
make 
for slow and complex code.

Back in the 70's, I read the "Pascal User Manual and Report", and decided to
try 
to write some programs in Pascal. Wirth had removed so many footguns, I could 
not write a useful program with it. It also just looked ugly. Wirth simply went 
too far. Subsequent implementations of Pascal had to add a lot of footguns to 
make it a useful language.



 There is a wide spectrum between the two extremes. You are here engaging in 
 unproductive black and white thinking.


I'm illustrating a point - that moving to "a language without footguns" is not 
practical. In solving engineering problems, a very productive way of settings
up 
is specifying the boundary conditions. Same here.

May I say you brought it up!



 Again, just watch your own keynote from last year's DConf. All airplanes can 
 crash, that does not mean all cockpit designs are equivalent.


I regularly emphasize "use your best judgement", not blindly following rules. I 
don't rigidly follow all the rules in my presentation, either.

Not matching C's and C++'s struct layouts by default is a pretty big footgun, 
and it includes the risk of memory corruption. One also would be less likely to 
have added tests for it.

Use of bitfields for externally imposed layouts is a frankly unusual case, and 
having one's layout not match it quite right is rather normal when doing such 
things. One would expect testing to cover it. It also is not a memory
corruption 
problem. I.e. it's a much smaller footgun.

P.S. What about extern(C) vs extern(D) functions? Is that a footgun? No,
because 
the linker will barf if your code conflates the two. The linker has no 
information on struct layouts. Neither does a shared library interface.

Iain has complained bitterly in the past, with 100% justification, that we'd 
change the struct layouts in the D front end and neglect to change the 
corresponding .h files. The result was always mysterious and difficult to find 
bugs. The end result was the tool to autogenerate frontend.h and compare it for 
differences. Do we really want to inflict that on our users by default?
Matching 
the layout is a big deal.
Jul 10
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
Walter,

Clearly: `extern(C)` and `extern(D)` bitfields would need to have 
compatible layouts for syntactically identical declarations that are 
accepted by both.

Please understand this simple point, otherwise it makes no sense to 
continue this debate.
Jul 11
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2024 3:00 AM, Timon Gehr wrote:

 Clearly: `extern(C)` and `extern(D)` bitfields would need to have compatible 
 layouts for syntactically identical declarations that are accepted by both.
 
 Please understand this simple point, otherwise it makes no sense to continue 
 this debate.


I've never disagreed with that.
Jul 19
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/11/24 04:40, Walter Bright wrote:

 On 7/10/2024 5:19 PM, Timon Gehr wrote:

 On 7/10/24 23:50, Walter Bright wrote:

 On 7/8/2024 4:18 PM, Timon Gehr wrote:

 The simple fact is that if you program in a language without 
 footguns, you are free to not worry about shooting your own foot. 
 (Assuming you like having feet.)


 A "footgun" is just another word for "bug".


 This is not true. A footgun in this context is something that 
 encourages the creation of bugs. A "footgun" is another word for 
 "error-prone design".


 
 2's complement arithmetic? Floating point arithmetic? Operator precedence?
 
 All of those are footguns.


2's complement arithmetic is indeed something people have complained 
about. I don't think `core.checkedint` is a good solution, but it should 
at least indicate that people were unsatisfied. I have complained about 
the D specification's approach to floating-point arithmetic in the past. 
Operator precedence is something that D actually innovated on in 
comparison to C in order to make it less error prone.


 We live with them because attempts to avoid 
 them make for slow and complex code.
 ...


This justification does not extend to everything that is a footgun. Some 
features are just unmitigated footguns, with essentially no upsides. 
Sometimes fixing a footgun is as simple as making syntax more explicit, 
as it is in this case.


 Back in the 70's, I read the "Pascal User Manual and Report", and 
 decided to try to write some programs in Pascal. Wirth had removed so 
 many footguns, I could not write a useful program with it. It also just 
 looked ugly. Wirth simply went too far. Subsequent implementations of 
 Pascal had to add a lot of footguns to make it a useful language.
 ...


ok.


 

 There is a wide spectrum between the two extremes. You are here 
 engaging in unproductive black and white thinking.


 
 I'm illustrating a point - that moving to "a language without footguns" 
 is not practical.


My point was not even that it is practical. :/ Please consider the 
context of my post.

Someone said that you have to choose between security and freedom, I 
said security is a form of freedom, someone doubted it. I therefore 
picked out an extreme (maybe unrealizable?) example to demonstrate that 
yes, security is indeed a form of freedom.


 In solving engineering problems, a very productive way 
 of settings up is specifying the boundary conditions. Same here.
 
 May I say you brought it up!
 ...


No, I don't think you can. Context matters. It is you who completely 
ignored the boundary conditions of my post and went off on a tangent.


 

 Again, just watch your own keynote from last year's DConf. All 
 airplanes can crash, that does not mean all cockpit designs are 
 equivalent.


 
 I regularly emphasize "use your best judgement",


I am.


 not blindly following 
 rules. I don't rigidly follow all the rules in my presentation, either.
 ...


I am not advocating rigidly following all rules in your presentation.

But when you of all people deviate, there should be a justification for 
it. You have so far failed to give one that is satisfactory. All you did 
was give justifications for _other_ footguns in the language, and you 
argued against footguns that are _not_ in the language, and that I am 
not even proposing. The only line of argument that would structurally 
work as a justification is your outlandish outright denial that C 
bitfields are a footgun, but this is so far removed from reality that it 
is unpersuasive as well.


 Not matching C's and C++'s struct layouts by default is a pretty big 
 footgun, and it includes the risk of memory corruption. One also would 
 be less likely to have added tests for it.
 ...


I agree. What is your point? Do you think best judgment would indicate 
that we need a footgun like that? I disagree.

If your point is actually that _I_ am in some way the one proposing 
layout mismatches, well I am not. You would be misrepresenting my point, 
utterly and absolutely.


 Use of bitfields


This is the memory safety thread, not the bitfield thread, but okay.


 for externally imposed layouts is a frankly unusual 
 case, and having one's layout not match it quite right is rather normal 
 when doing such things. One would expect testing to cover it. It also is 
 not a memory corruption problem. I.e. it's a much smaller footgun.
 ...


Differences in layout may also move pointers around, even if the 
differences originate from bitfields.


 P.S. What about extern(C) vs extern(D) functions? Is that a footgun? No, 
 because the linker will barf if your code conflates the two.


Well, what am I to say? I approve. This is sane. Why is it sane? Because 
`extern(D)` somewhat deviates from C insanity, by mangling names.


 The linker has no information on struct layouts.


This is why, clearly, `extern(C)` and `extern(D)` bitfields would need 
to have compatible layouts for code that is accepted by both.

(Anyway, arguably it could also be a good idea to put a hash of the 
struct layout in mangled names.)


 Neither does a shared library 
 interface.
 
 Iain has complained bitterly in the past, with 100% justification, that 
 we'd change the struct layouts in the D front end and neglect to change 
 the corresponding .h files. The result was always mysterious and 
 difficult to find bugs. The end result was the tool to autogenerate 
 frontend.h and compare it for differences. Do we really want to inflict 
 that on our users by default?


No, of course we do not want to inflict that on our users by default... 
Note the structure of your argument here, which is "look at this insane 
C footgun design!". I am the one proposing more layout sanity in this 
situation. You are the one advocating for less sanity in layouts. Please 
stop trying to somehow pretend it is the other way around. It's tiresome.


 Matching the layout is a big deal.
 


Of course!
Jul 11
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2024 3:09 AM, Timon Gehr wrote:

 If your point is actually that _I_ am in some way the one proposing layout 
 mismatches, well I am not. You would be misrepresenting my point, utterly and 
 absolutely.


Then I apologize, for I thought that was your proposal.
Jul 19
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/19/24 20:06, Walter Bright wrote:

 On 7/11/2024 3:09 AM, Timon Gehr wrote:

 If your point is actually that _I_ am in some way the one proposing 
 layout mismatches, well I am not. You would be misrepresenting my 
 point, utterly and absolutely.


 
 Then I apologize, for I thought that was your proposal.
 


My proposal has been to check for bitfield layout best practices by 
default, to the point of maximum portability.

Explicit `extern(C)` would be required to turn the checks off.

I.e., compatible layouts, but D would be more sane.
Jul 20
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2024 8:55 AM, Timon Gehr wrote:

 My proposal has been to check for bitfield layout best practices by default,
to 
 the point of maximum portability.
 Explicit `extern(C)` would be required to turn the checks off.
 
 I.e., compatible layouts, but D would be more sane.


Ok, I understand that.
Jul 22
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 8 July 2024 at 15:27:49 UTC, Timon Gehr wrote:

 On 7/6/24 16:56, aberba wrote:

  From another angle, would you choose "less freedom but more 
 security" or "more freedom but less security"? You can't have 
 both.


 Arguably, security is a form of freedom.


"You'll own and control nothing, but you'll be happy"
Jul 08
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 7/8/24 23:56, aberba wrote:

 On Monday, 8 July 2024 at 15:27:49 UTC, Timon Gehr wrote:

 On 7/6/24 16:56, aberba wrote:

  From another angle, would you choose "less freedom but more 
 security" or "more freedom but less security"? You can't have both.


 Arguably, security is a form of freedom.


 
 "You'll own and control nothing, but you'll be happy"


That has nothing to do with what I said.
Jul 08
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 6 July 2024 at 11:07:32 UTC, Sebastian Nibisz wrote:

 On Saturday, 6 July 2024 at 00:21:32 UTC, Walter Bright wrote:

 On 7/5/2024 12:42 PM, Steven Schveighoffer wrote:

 Yes, I'm aware. I purposely did not apply ` safe`. D is not a 
 memory safe language, you have to request it.


 D is memory safe if you type in "safe:" and use the gc.

 https://dlang.org/spec/memory-safe-d.html


 Seriously? Any language is safe in this case, you just need to 
 write safe code.


..... 1 line of code is small enough
Jul 06
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, July 6, 2024 5:07:32 AM MDT Sebastian Nibisz via Digitalmars-d 
wrote:

 On Saturday, 6 July 2024 at 00:21:32 UTC, Walter Bright wrote:

 On 7/5/2024 12:42 PM, Steven Schveighoffer wrote:

 Yes, I'm aware. I purposely did not apply ` safe`. D is not a
 memory safe language, you have to request it.


 D is memory safe if you type in "safe:" and use the gc.

 https://dlang.org/spec/memory-safe-d.html


 Seriously? Any language is safe in this case, you just need to
 write safe code.


The point is that D provides checks for memory safety if you choose to
enable them. It requires using  safe to explicitly say that you want a piece
of code to have those checks done, so the checks are not on by default, but
it _does_ provide such checks, whereas a language like C/C++ does not. D has
also been designed in a way to try to eliminate a lot of the undefined and
unsafe behaviors that you have to be careful to avoid in C/C++. Barring
compiler bugs or the programmer screwing up with  trusted,  safe code in D
is guaranteed to be memory safe, whereas in C/C++, the language is not
designed to avoid memory safety issues, and it's entirely up to the
programmer to use the language in a way that doesn't have memory safety
problems.

Making  safe the default for D would have the benefit of making it so that
you get those memory safety checks by default, but it doesn't actually make
the language itself safer. It has the same tools either way.

- Jonathan M Davis
Jul 06
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:

 Seriously? Any language is safe in this case, you just need to write safe code.


Enabling the checks is quite different from writing code with no bugs in it.
Jul 06
next sibling parent Lance Bachmeier <no spam.net> writes:
On Saturday, 6 July 2024 at 23:10:02 UTC, Walter Bright wrote:

 On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:

 Seriously? Any language is safe in this case, you just need to 
 write safe code.


 Enabling the checks is quite different from writing code with 
 no bugs in it.


Correct. If ` safe:` is too much to add to the program, then how 
do you know ` trusted:` didn't slip in somewhere? You'd have to 
remove the possibility of writing unsafe code if those are the 
constraints.
Jul 06
prev sibling parent reply Sebastian Nibisz <snibisz gmail.com> writes:
On Saturday, 6 July 2024 at 23:10:02 UTC, Walter Bright wrote:

 On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:

 Seriously? Any language is safe in this case, you just need to 
 write safe code.


 Enabling the checks is quite different from writing code with 
 no bugs in it.


But you have to remember to enable it. Inexperienced programmer 
usually won't do this and will build unsafe code unconsciously.
Jul 06
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/6/2024 4:39 PM, Sebastian Nibisz wrote:

 But you have to remember to enable it. Inexperienced programmer usually won't
do 
 this and will build unsafe code unconsciously.


 safe should be the default. But that breaks existing code. So we do the best
we 
can.
Jul 06
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 6 July 2024 at 23:39:54 UTC, Sebastian Nibisz wrote:

 On Saturday, 6 July 2024 at 23:10:02 UTC, Walter Bright wrote:

 On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:

 Seriously? Any language is safe in this case, you just need 
 to write safe code.


 Enabling the checks is quite different from writing code with 
 no bugs in it.


 But you have to remember to enable it. Inexperienced programmer 
 usually won't do this and will build unsafe code unconsciously.


I've heard this argument about the "inexperienced programmer" 
many times. Folks assume inexperienced programmers are writing 
some kernel code or deploying to some mission critical system. I 
see an inexperienced programmer writing any such code anytime 
soon. They could care less about these things you're talking 
about and they'd be using the GC (not that GC is a beginner 
target feature). Many of the traditional languages suggested to 
beginners such as C, C++, Python, JavaScript, PHP don't work like 
rust.

I'm not arguing writing memory unsafe code should be encouraged, 
I'm saying in reality, it's not a problem for the beginner. You 
can still write bugs causing vulnerabilities in any language.

Have you considered the cons of dealing with  safe code?
Jul 08
parent reply Martyn <martyn.developer googlemail.com> writes:
On Monday, 8 July 2024 at 07:23:44 UTC, aberba wrote:

 On Saturday, 6 July 2024 at 23:39:54 UTC, Sebastian Nibisz 
 wrote:

 On Saturday, 6 July 2024 at 23:10:02 UTC, Walter Bright wrote:

 On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:

 Seriously? Any language is safe in this case, you just need 
 to write safe code.


 Enabling the checks is quite different from writing code with 
 no bugs in it.


 But you have to remember to enable it. Inexperienced 
 programmer usually won't do this and will build unsafe code 
 unconsciously.


 I've heard this argument about the "inexperienced programmer" 
 many times. Folks assume inexperienced programmers are writing 
 some kernel code or deploying to some mission critical system. 
 I see an inexperienced programmer writing any such code anytime 
 soon. They could care less about these things you're talking 
 about and they'd be using the GC (not that GC is a beginner 
 target feature). Many of the traditional languages suggested to 
 beginners such as C, C++, Python, JavaScript, PHP don't work 
 like rust.

 I'm not arguing writing memory unsafe code should be 
 encouraged, I'm saying in reality, it's not a problem for the 
 beginner. You can still write bugs causing vulnerabilities in 
 any language.

 Have you considered the cons of dealing with  safe code?



I generally agree.

If any Company **MUST** write memory-safe code then there should 
be rules/standards to follow whether starting a new programming 
project, to having code reviews and deployment, or other 
variations.

For example, code reviews should be completed by senior/lead 
programmers, especially if there has been commits from 
junor-level programmers... though it should be reviewed 
**REGARDLESS** of who and their level of experience.

I do not see Dlang being any different in comparison to other, 
memory-safe languages. Even if the Company was using Rust, there 
**should** still be rules and guidelines to follow! Just because 
a language is safe by default does not mean un-safe code cannot 
creep in!

I personally am not bothered if a language is or isn't 
memory-safe by default. However, the reality is memory-safe by 
default will get a big green tick beside it when it comes to 
research papers... and they are the only ones that will get 
copied-pasted into media/blog articles moving forward.

Rust is all the buzz at the moment and, no doubt, will be the top 
talking point for these sites whether the writer has any 
programming knowledge or not.


I guess if Dlang: -

* goes memory-safe by default, will break existing code.
* continues as is, will not get recognition for those articles.

For every new DMD release, should there be a SafeDMD alongside 
it, forcing  safe by default? Would this satisfy both points?
Jul 08
parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 8 July 2024 at 08:48:56 UTC, Martyn wrote:

 * goes memory-safe by default, will break existing code.


The idea is that the next 
[edition](https://forum.dlang.org/post/tskwospngntbnqiuxbag forum.dlang.org) is
 safe by default. Existing code will not be broken.
Jul 08
parent reply bachmeier <no spam.net> writes:
On Monday, 8 July 2024 at 10:30:56 UTC, Nick Treleaven wrote:

 On Monday, 8 July 2024 at 08:48:56 UTC, Martyn wrote:

 * goes memory-safe by default, will break existing code.


 The idea is that the next 
 [edition](https://forum.dlang.org/post/tskwospngntbnqiuxbag forum.dlang.org)
is  safe by default. Existing code will not be broken.


We have very few details on what this will look like for someone 
that doesn't want it. Not breaking existing code is far from 
sufficient for those writing unsafe code. Inference is useless 
because there's nothing to infer,  trusted loses its meaning, 
there's needless boilerplate all over the place, and it's more 
complex for new users of the language. There's no evidence that 
any of this has been given consideration, and all apparently 
because adding -safe to the compilation command is too much of a 
burden for those wanting the additional checks.
Jul 08
next sibling parent reply Dom DiSc <dominikus scherkl.de> writes:
On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:

 We have very few details on what this will look like for 
 someone that doesn't want it. Not breaking existing code is far 
 from sufficient for those writing unsafe code.


Sorry, but having unsafe code is burden enough.
I don't see any need to help people continue to write unsafe code.
If at all, it is enough that it will be still possible to write 
unsafe code. Its not required to make that easy. Why can't those 
people be bothered with giving -unsafe as compile parameter? (Or 
even something more sofisticated)

IT SHOULD ALWAYS BE MORE COMPLICATED TO SHOOT YOUR FOOT THAN 
AVOIDING IT
Jul 08
next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 8 July 2024 at 14:08:49 UTC, Dom DiSc wrote:

 On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:

 We have very few details on what this will look like for 
 someone that doesn't want it. Not breaking existing code is 
 far from sufficient for those writing unsafe code.


 Sorry, but having unsafe code is burden enough.


This is not helpful. If the biggest selling point is working with 
legacy C code, unsafe code needs to be a core part of the 
language, and it needs to be as easy as possible. (As in, as easy 
as it is right now.)


 I don't see any need to help people continue to write unsafe 
 code.


D will quickly die without unsafe code. I would certainly have no 
reason to continue using it. Rust has the small market for "safe 
by default" code. D can not and will not compete with Rust on 
this - the battle is over and all parties have moved on.


 If at all, it is enough that it will be still possible to write 
 unsafe code. Its not required to make that easy.


We can already do it. There's no "make that easy" to do.


 Why can't those people be bothered with giving -unsafe as 
 compile parameter?


Proposed and rejected. Whereas safe by default is already 
available with a switch.
Jul 08
next sibling parent reply Brian Callahan <bcallah openbsd.org> writes:
On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

 Whereas safe by default is already available with a switch.


What is the switch for that?
Jul 09
parent reply Lance Bachmeier <no spam.net> writes:
On Tuesday, 9 July 2024 at 11:54:31 UTC, Brian Callahan wrote:

 On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

 Whereas safe by default is already available with a switch.


 What is the switch for that?


Walter added -preview=safedefault when he started working on 
this. I haven't paid attention to it, so I don't know if it's 
still there, but there was such a switch: 
https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md#description
Jul 09
parent Brian Callahan <bcallah openbsd.org> writes:
On Tuesday, 9 July 2024 at 14:25:06 UTC, Lance Bachmeier wrote:

 On Tuesday, 9 July 2024 at 11:54:31 UTC, Brian Callahan wrote:

 On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

 Whereas safe by default is already available with a switch.


 What is the switch for that?


 Walter added -preview=safedefault when he started working on 
 this. I haven't paid attention to it, so I don't know if it's 
 still there, but there was such a switch: 
 https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md#description


Sadly with DMD v2.109.0:
Error: preview `-preview=safedefault` is invalid

~Brian
Jul 09
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

 On Monday, 8 July 2024 at 14:08:49 UTC, Dom DiSc wrote:

 On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:

 We have very few details on what this will look like for 
 someone that doesn't want it. Not breaking existing code is 
 far from sufficient for those writing unsafe code.


 Sorry, but having unsafe code is burden enough.


 This is not helpful. If the biggest selling point is working 
 with legacy C code, unsafe code needs to be a core part of the 
 language, and it needs to be as easy as possible. (As in, as 
 easy as it is right now.)


 I don't see any need to help people continue to write unsafe 
 code.


 D will quickly die without unsafe code. I would certainly have 
 no reason to continue using it. Rust has the small market for 
 "safe by default" code. D can not and will not compete with 
 Rust on this - the battle is over and all parties have moved on.


 If at all, it is enough that it will be still possible to 
 write unsafe code. Its not required to make that easy.


 We can already do it. There's no "make that easy" to do.


 Why can't those people be bothered with giving -unsafe as 
 compile parameter?


 Proposed and rejected. Whereas safe by default is already 
 available with a switch.


+1

AI devs picked C, not rust
Jul 10
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 10 July 2024 at 16:06:50 UTC, ryuukk_ wrote:

 AI devs picked C, not rust


Not sure about that actually.
Many things already started implementing in Rust...
One of the most popular tokenizers (state of the art .. blah blah 
blah)
https://github.com/huggingface/tokenizers

Hugging Face has a lot of Rust repos.
Of course some old stuff like CUDA and libtorch are still C++.. 
but they've started many years ago
Jul 10
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 10 July 2024 at 18:42:21 UTC, Sergey wrote:

 On Wednesday, 10 July 2024 at 16:06:50 UTC, ryuukk_ wrote:

 AI devs picked C, not rust


 Not sure about that actually.
 Many things already started implementing in Rust...
 One of the most popular tokenizers (state of the art .. blah 
 blah blah)
 https://github.com/huggingface/tokenizers

 Hugging Face has a lot of Rust repos.
 Of course some old stuff like CUDA and libtorch are still C++.. 
 but they've started many years ago


Except them, there is nothing

Besides, calling a tokenizer "tokenierz".. they play the SEO game 
with the VCs, the steam remains C
Jul 10
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 10 July 2024 at 16:06:50 UTC, ryuukk_ wrote:

 On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

 On Monday, 8 July 2024 at 14:08:49 UTC, Dom DiSc wrote:

 On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:

 We have very few details on what this will look like for 
 someone that doesn't want it. Not breaking existing code is 
 far from sufficient for those writing unsafe code.


 Sorry, but having unsafe code is burden enough.


 This is not helpful. If the biggest selling point is working 
 with legacy C code, unsafe code needs to be a core part of the 
 language, and it needs to be as easy as possible. (As in, as 
 easy as it is right now.)


 I don't see any need to help people continue to write unsafe 
 code.


 D will quickly die without unsafe code. I would certainly have 
 no reason to continue using it. Rust has the small market for 
 "safe by default" code. D can not and will not compete with 
 Rust on this - the battle is over and all parties have moved 
 on.


 If at all, it is enough that it will be still possible to 
 write unsafe code. Its not required to make that easy.


 We can already do it. There's no "make that easy" to do.


 Why can't those people be bothered with giving -unsafe as 
 compile parameter?


 Proposed and rejected. Whereas safe by default is already 
 available with a switch.


 +1

 AI devs picked C, not rust


They picked C++, CUDA and Python JIT compilers, alongside Java, 
Scala, C++, and Rust for the tools used in big data ecosystem 
like Spark and Arrow.

Pytorch and Tensorflow, use C++ with Python and Java bindings.

Depending on how sucessful, Modular's agreement with NVidia turns 
out, they might pick Mojo as well.

C not really part of the story beyond being Python's FFI ABI.
Jul 11
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 8 July 2024 at 14:08:49 UTC, Dom DiSc wrote:

 
 IT SHOULD ALWAYS BE MORE COMPLICATED TO SHOOT YOUR FOOT THAN 
 AVOIDING IT


A dull knife is the dangerous one, safety features just get in 
the way and you'll get people learning actively awful patterns in 
an attempt to force the tool to work

To say nothing of the lack of understanding of fail safe vs fail 
dangerous in cs, safetyphilia is is misplaced and delusional in 
the degree which I will adopt any of it for a single second. I 
won't.
Jul 08
parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 8 July 2024 at 14:46:47 UTC, monkyyy wrote:

 A dull knife is the dangerous one, safety features just get in 
 the way and you'll get people learning actively awful patterns 
 in an attempt to force the tool to work


Any pattern to subvert safe involves the ` trusted` attribute 
(except for compiler bugs, which editions help to fix). 
` trusted` is an obvious flag in code review that memory-safety 
may be violated. Grepping for ` trusted` is an easy way to narrow 
down places where memory-safety is violated.

Arguing that  trusted can be abused is a tiny problem compared to 
the far harder to detect abuse in  system by default code.
Jul 09
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 9 July 2024 at 15:58:17 UTC, Nick Treleaven wrote:

 On Monday, 8 July 2024 at 14:46:47 UTC, monkyyy wrote:

 A dull knife is the dangerous one, safety features just get in 
 the way and you'll get people learning actively awful patterns 
 in an attempt to force the tool to work


 Any pattern to subvert safe involves the ` trusted` attribute 
 (except for compiler bugs, which editions help to fix).



 Any


nah; trusted helps make a pressure release valve which will 
prevent the truly pathological situations of say rust or 
enterprise grade fizzbuzz but.....

The way I will subvert the safety features will be entirely 
unpredictable, we wont know till im forced to learn what safe 
actually does, if Im writting ` trusted:` at the top of files 
next to my `import std` all`y`alls will be lucky; if its more 
like how I made an "appendable alias seq", well theres only like 
3 poeple who understood those mere 80 lines of code
Jul 09
parent reply aberba <karabutaworld gmail.com> writes:
On Tuesday, 9 July 2024 at 16:18:27 UTC, monkyyy wrote:

 On Tuesday, 9 July 2024 at 15:58:17 UTC, Nick Treleaven wrote:

 On Monday, 8 July 2024 at 14:46:47 UTC, monkyyy wrote:

 A dull knife is the dangerous one, safety features just get 
 in the way and you'll get people learning actively awful 
 patterns in an attempt to force the tool to work


 Any pattern to subvert safe involves the ` trusted` attribute 
 (except for compiler bugs, which editions help to fix).



 Any




.

 like how I made an "appendable alias seq", well theres only 
 like 3 poeple who understood those mere 80 lines of code


I feel the same about the abuse of templates in a lot of D code. 
Suddenly no one wants to touch, maintain or contribute.

Now the cognitive load will be more with  safe on top.
Jul 09
parent monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 9 July 2024 at 21:13:19 UTC, aberba wrote:

 

 like how I made an "appendable alias seq", well theres only 
 like 3 poeple who understood those mere 80 lines of code


 I feel the same about the abuse of templates in a lot of D 
 code. Suddenly no one wants to touch, maintain or contribute.

 Now the cognitive load will be more with  safe on top.


I love template, Im here for templates

function coloring and appending erroneous "nah you you must do 
busy work" errors is actively irritating; death to any lanaguge 
with opinionated white space, unused imports, safety begging, 
unreachable statement type errors
Jul 09
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2024 8:58 AM, Nick Treleaven wrote:

 Any pattern to subvert safe involves the ` trusted` attribute (except for 
 compiler bugs, which editions help to fix). ` trusted` is an obvious flag in 
 code review that memory-safety may be violated. Grepping for ` trusted` is an 
 easy way to narrow down places where memory-safety is violated.
 
 Arguing that  trusted can be abused is a tiny problem compared to the far
harder 
 to detect abuse in  system by default code.


That's right. Converting an entire program to  safe can be done successfully by 
doing it incrementally, getting it to pass its test suite at each step. The way 
to do it incrementally is to start by labeling each function  trusted, then 
making them  safe one by one.

I've done this, it works.

And, as you observe, grepping for " trusted" makes for a builtin-in TODO list!
Jul 11
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 11 July 2024 at 16:26:59 UTC, Walter Bright wrote:

 On 7/9/2024 8:58 AM, Nick Treleaven wrote:

 [...]


 That's right. Converting an entire program to  safe can be done 
 successfully by doing it incrementally, getting it to pass its 
 test suite at each step. The way to do it incrementally is to 
 start by labeling each function  trusted, then making them 
  safe one by one.

 I've done this, it works.

 And, as you observe, grepping for " trusted" makes for a 
 builtin-in TODO list!


This to me is the most sensible way to go about it.
Jul 13
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/13/24 14:37, aberba wrote:

 On Thursday, 11 July 2024 at 16:26:59 UTC, Walter Bright wrote:

 On 7/9/2024 8:58 AM, Nick Treleaven wrote:

 [...]


 That's right. Converting an entire program to  safe can be done 
 successfully by doing it incrementally, getting it to pass its test 
 suite at each step. The way to do it incrementally is to start by 
 labeling each function  trusted, then making them  safe one by one.

 I've done this, it works.

 And, as you observe, grepping for " trusted" makes for a builtin-in 
 TODO list!


 
 This to me is the most sensible way to go about it.


It's not. You'll quickly lose track of the 3 kinds of ` trusted` functions:

-  trusted functions that should be  safe
-  trusted functions that should be  trusted
-  trusted functions that must be  system

This is plain safewashing.

If you want incremental safety in the current language, you have to 
start at the leaves, and put your TODO's in comments.

OpenD has an interesting approach towards default safety. They enabled a 
large fraction of safety checks in functions without a safety 
annotation. To disable them, explicit  system is required. This way you 
get linting benefits even without already ensuring full memory safety 
guarantees.

Anyway, there are many language-assisted ways to make incremental  safe 
migration work (some would require only minimal changes to the 
compiler), but I think slapping  trusted everywhere will not do anything 
to improve the perceptions about D's memory safety.
Jul 13
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 13 July 2024 at 13:09:14 UTC, Timon Gehr wrote:

 On 7/13/24 14:37, aberba wrote:

 On Thursday, 11 July 2024 at 16:26:59 UTC, Walter Bright wrote:

 [...]


 
 This to me is the most sensible way to go about it.


 It's not. You'll quickly lose track of the 3 kinds of 
 ` trusted` functions:

 -  trusted functions that should be  safe
 -  trusted functions that should be  trusted
 -  trusted functions that must be  system

 This is plain safewashing.

 If you want incremental safety in the current language, you 
 have to start at the leaves, and put your TODO's in comments.

 OpenD has an interesting approach towards default safety. They 
 enabled a large fraction of safety checks in functions without 
 a safety annotation. To disable them, explicit  system is 
 required. This way you get linting benefits even without 
 already ensuring full memory safety guarantees.

 Anyway, there are many language-assisted ways to make 
 incremental  safe migration work (some would require only 
 minimal changes to the compiler), but I think slapping  trusted 
 everywhere will not do anything to improve the perceptions 
 about D's memory safety.


I would add one point, Walter wrote in his original port:

"In fact, I've been doing just that. Adding  safe: at the top, 
and then everything that fails to compile gets marked  trusted. 
****Eventually****, refactor the code as time permits."

Ouch!
Jul 13
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/13/2024 6:09 AM, Timon Gehr wrote:

 This to me is the most sensible way to go about it.


 
 It's not. You'll quickly lose track of the 3 kinds of ` trusted` functions:
 
 -  trusted functions that should be  safe
 -  trusted functions that should be  trusted
 -  trusted functions that must be  system
 
 This is plain safewashing.


Not if the  trusted functions have a safe interface (though the compiler cannot 
check the interface for safety, it is up to the programmer).



 If you want incremental safety in the current language, you have to start at
the 
 leaves, and put your TODO's in comments.


In my efforts to make the front end  safe, that approach does not work. The 
problem is that the front end flow graph is cyclical. There aren't many leaves, 
and a lot of those leaves in the front end have been marked as  safe.



 OpenD has an interesting approach towards default safety. They enabled a large 
 fraction of safety checks in functions without a safety annotation. To disable 
 them, explicit  system is required. This way you get linting benefits even 
 without already ensuring full memory safety guarantees.


It's an interesting approach, but certainly half-baked. How does one decide 
which safety checks are to be included?



 Anyway, there are many language-assisted ways to make incremental  safe 
 migration work (some would require only minimal changes to the compiler), but
I 
 think slapping  trusted everywhere will not do anything to improve the 
 perceptions about D's memory safety.


You've often been quite adamant about memory safety being 100% (and I tend to 
appreciate that point of view and am in agreement with it). A half-baked 
approach won't help, either.

With the  trusted approach, I'll often change it to  safe, fix what I can, then 
put it back to  trusted.
Jul 13
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/13/24 21:27, Walter Bright wrote:

 On 7/13/2024 6:09 AM, Timon Gehr wrote:

 This to me is the most sensible way to go about it.


 It's not. You'll quickly lose track of the 3 kinds of ` trusted` 
 functions:

 -  trusted functions that should be  safe
 -  trusted functions that should be  trusted
 -  trusted functions that must be  system

 This is plain safewashing.


 
 Not if the  trusted functions have a safe interface (though the compiler 
 cannot check the interface for safety, it is up to the programmer).
 ...


Well, your suggestion was to put  trusted _everywhere_, not only on 
functions with a safe interface. As Dennis points out, it seems that is 
exactly what happened in some instances.

Anyway, ` trusted` indicates that whoever put it there reviewed the 
implementation for memory safety. This makes this approach impractical.


 

 If you want incremental safety in the current language, you have to 
 start at the leaves, and put your TODO's in comments.


 
 In my efforts to make the front end  safe, that approach does not work. 
 The problem is that the front end flow graph is cyclical. There aren't 
 many leaves, and a lot of those leaves in the front end have been marked 
 as  safe.
 ...


The solution is to remove the unsafe constructs and then mark everything 
safe in one go. The compiler currently cannot assist with this very 
well, but it is easy to do. It should just have a way to enable 
non-transitive safety checks.


 

 OpenD has an interesting approach towards default safety. They enabled 
 a large fraction of safety checks in functions without a safety 
 annotation. To disable them, explicit  system is required. This way 
 you get linting benefits even without already ensuring full memory 
 safety guarantees.


 
 It's an interesting approach, but certainly half-baked. How does one 
 decide which safety checks are to be included?
 ...


In a data-driven way. They enabled the checks that do not cause too much 
pain to users. OpenD is a big monorepository with DMD, LDC, and most of 
the packages that people actually use, so breaking changes actually 
require breakage to be fixed as well.

Anyway, non-transitive checks can be a useful tool for all function 
attributes, and they have the benefit of not over-specifying their 
guarantees. This can even be done with pragmas. I implemented a simple 
pragma to (non-transitively) error out on implicit GC allocations, and 
it was helpful for performance optimization.


 

 Anyway, there are many language-assisted ways to make incremental 
  safe migration work (some would require only minimal changes to the 
 compiler), but I think slapping  trusted everywhere will not do 
 anything to improve the perceptions about D's memory safety.


 
 You've often been quite adamant about memory safety being 100% (and I 
 tend to appreciate that point of view and am in agreement with it).


Yes,  safe should mean memory safe. It should not mean: We'd like this 
to be memory safe, but it is work in progress.


 A half-baked approach won't help, either.
 ...


Well, if the goal is incremental migration to ` safe`, a process of 
enabling non-transitive safety checks on a function-by-function basis 
and then later making it transitive is much more baked than random 
application of  trusted, and it completely bypasses any issues with big 
cyclic call graphs.


 With the  trusted approach, I'll often change it to  safe, fix what I 
 can, then put it back to  trusted.


The fake-` trusted` approach is half-baked, error prone, and undercuts 
 safe. The fully baked way is to provide actual tooling for the use case 
of incremental migration to memory safety.
Jul 13
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/13/2024 2:46 PM, Timon Gehr wrote:

 Well, your suggestion was to put  trusted _everywhere_, not only on functions 
 with a safe interface. As Dennis points out, it seems that is exactly what 
 happened in some instances.


That is correct.


 Anyway, ` trusted` indicates that whoever put it there reviewed the 
 implementation for memory safety. This makes this approach impractical.


You could call it unwise, or a footgun, or introducing technical debt. But it
is 
practical.

If a surgeon wants to fix a man's heart, first he's going to make things worse 
by slicing him open like a side of beef.

If a mechanic wants to rebuilt an engine, first he has to dismantle a fair
chunk 
of the car, making things worse.



 The solution is to remove the unsafe constructs and then mark everything safe
in 
 one go. The compiler currently cannot assist with this very well, but it is
easy 
 to do. It should just have a way to enable non-transitive safety checks.


In my experience with large, complex programs, cyclical program flow, that is 
not practical. I wish it was practical.



 In a data-driven way. They enabled the checks that do not cause too much pain
to 
 users. OpenD is a big monorepository with DMD, LDC, and most of the packages 
 that people actually use, so breaking changes actually require breakage to be 
 fixed as well.


I also incrementally fix  safe issues, by making a function temporarily  safe, 
and fixing what I can. But that does not solve the cyclical dependency problems.



 Anyway, non-transitive checks can be a useful tool for all function
attributes, 
 and they have the benefit of not over-specifying their guarantees. This can
even 
 be done with pragmas. I implemented a simple pragma to (non-transitively)
error 
 out on implicit GC allocations, and it was helpful for performance
optimization.


An easier way is just add ` nogc:`, fix all the errors you need to, then remove
it.



 Well, if the goal is incremental migration to ` safe`, a process of enabling 
 non-transitive safety checks on a function-by-function basis and then later 
 making it transitive is much more baked than random application of  trusted,
and 
 it completely bypasses any issues with big cyclic call graphs.


There is a way:

1. add  safe:

2. fix what you can

3. remove  safe:

No new features required.
Jul 19
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Friday, 19 July 2024 at 18:19:38 UTC, Walter Bright wrote:

 In my experience with large, complex programs, cyclical program 
 flow, that is not practical. I wish it was practical.


I assume you're mostly referring to dmd. I've also been 
incrementally improving dmd's own safety over the years, but by 
working bottom up, without marking functions with unsafe 
interfaces ` trusted`. How do the strategies compare? One 
approximation would be to simply count additions / deletions of 
` safe`, ` system` and ` trusted` in our commits over the last 5 
years:

```
 From me:
    safe:    +1048 -245
    trusted:  +109 -181
    system:   +166 -302

 From you:
    safe:     +315 -142
    trusted: +1331  -46
    system:   +242  -14
```

(Generated by 
https://gist.github.com/dkorpel/666aa59e0b910713f614382f563e89b4 
and dmd-master today)

Take these numbers with a grain of salt: this doesn't analyze the 
scope and actual impact of those attributes of course. However, 
it's hard to believe mass-applying ` trusted` on functions is 
'the only practical way'.

In my experience, the main obstacles of a ` safe` dmd are 
abundant use of `__gshared` and C-strings. That's why I 
appreciate your pull requests where you refactor globals into 
parameters, those improve the ` safe` situation for real. The DIP 
idea to make printf's interface ` safe` is also a step in the 
right direction because `error()` calls are everywhere. (though 
with the bootstrap compiler situation, its usefulness looks very 
far away).
Jul 19
parent reply Walter Bright <newshound2 digitalmars.com> writes:
I appreciate your help with this!

On 7/19/2024 12:43 PM, Dennis wrote:

 Take these numbers with a grain of salt: this doesn't analyze the scope and 
 actual impact of those attributes of course. However, it's hard to believe 
 mass-applying ` trusted` on functions is 'the only practical way'.


The hard problems aren't being tackled, like toChars(). One would think it
would 
be a leaf, but it isn't. It can call semantic(), semantic() can call the
parser, 
and round and round it goes.

There's no place to start.

I haven't found a better way. You saw the problems I had with pretregs in the 
backend. I finally had to bite the bullet and do a very large PR. And that was 
simple to do, though very tedious.  safe changes need re-engineering, not just 
query-search-replace.

I've done similar things in the past. What works is doing things incrementally, 
passing the test suite with each increment. What doesn't work is do it all at
once.



 In my experience, the main obstacles of a ` safe` dmd are abundant use of 
 `__gshared` and C-strings. That's why I appreciate your pull requests where
you 
 refactor globals into parameters, those improve the ` safe` situation for
real. 
 The DIP idea to make printf's interface ` safe` is also a step in the right 
 direction because `error()` calls are everywhere.


That's one reason to switch to parameters, but there's another: make the 
compiler "stateless" so it can be a library.


 (though with the bootstrap compiler situation, its usefulness looks very far 


away).

I don't know why the bootstrap compiler needs to be so old? Back in the olden 
daze of my compiler, the previous release was the bootstrap version!
Jul 24
parent Dennis <dkorpel gmail.com> writes:
On Thursday, 25 July 2024 at 02:04:57 UTC, Walter Bright wrote:

 I appreciate your help with this!


Thanks!


 The hard problems aren't being tackled, like toChars().

 There's no place to start.


Well, giving a safe interface to `error` and replacing `toChars` 
with `toString` is a start.


 What works is doing incrementally, passing the test suite with 
 each increment. What doesn't work is do it all at once.


Agreed, but you can also incrementally replace unsafe interfaces 
with safe ones. No need to put ` trusted` on unsafe interfaces.


 I don't know why the bootstrap compiler needs to be so old?


We have to ask Iain. The latest PR trying to bump it from 2.076 
to 2.083 got closed: https://github.com/dlang/dmd/pull/16158
Jul 25
prev sibling parent reply claptrap <clap trap.com> writes:
On Friday, 19 July 2024 at 18:19:38 UTC, Walter Bright wrote:

 On 7/13/2024 2:46 PM, Timon Gehr wrote:

 Well, your suggestion was to put  trusted _everywhere_, not 
 only on functions with a safe interface. As Dennis points out, 
 it seems that is exactly what happened in some instances.


 That is correct.


 Anyway, ` trusted` indicates that whoever put it there 
 reviewed the implementation for memory safety. This makes this 
 approach impractical.


 You could call it unwise, or a footgun, or introducing 
 technical debt. But it is practical.

 If a surgeon wants to fix a man's heart, first he's going to 
 make things worse by slicing him open like a side of beef.


They use keyhole surgery for a lot of heart ops these days, they 
fit new values by going in through a vein in your leg for example.



 If a mechanic wants to rebuilt an engine, first he has to 
 dismantle a fair chunk of the car, making things worse.


I think you're making a false equivalence.

Your argument for doing it the way you have is that it's the most 
effective way of doing it, not that it's the only way to do it. 
If it were unavoidable there wouldn't even be a debate about it.
Jul 22
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 7/22/24 21:06, claptrap wrote:

 

 If a mechanic wants to rebuilt an engine, first he has to dismantle a 
 fair chunk of the car, making things worse.


 
 I think you're making a false equivalence.


I agree. Walter's approach is more like the Volkswagen emission scandal.
Jul 22
prev sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Saturday, 13 July 2024 at 19:27:02 UTC, Walter Bright wrote:

 On 7/13/2024 6:09 AM, Timon Gehr wrote:

 OpenD has an interesting approach towards default safety. They 
 enabled a large fraction of safety checks in functions without 
 a safety annotation. To disable them, explicit  system is 
 required. This way you get linting benefits even without 
 already ensuring full memory safety guarantees.


 It's an interesting approach, but certainly half-baked. How 
 does one decide which safety checks are to be included?


I’d bet all it’s of them except the one telling you that you 
can’t call a ` system` function from a ` safe` function.
Jul 22
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 11 July 2024 at 16:26:59 UTC, Walter Bright wrote:

 The way to do it incrementally is to start by labeling each 
 function  trusted, then making them  safe one by one.

 I've done this, it works.


I know you've done the first part, because there's now 1122 
` trusted` functions in  dmd.backend. Many of them have an unsafe 
interface such as:

```D
 trusted
void list_delete(list_t list) { free(list); }
```

Not much actual ` safe` code has come from it unfortunately.
Jul 13
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/13/2024 10:16 AM, Dennis wrote:

 Not much actual ` safe` code has come from it unfortunately.


That's because the design of it resists  safe requirements.

For a major one, there's `struct elem`:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/el.d#L69

Note the union in it, which maps pointers on top of non-pointers. This is 
detected as unsafe. And it is unsafe! (But it works.)

Use of `struct elem` permeates the backend.

Then there is the `struct code`:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/x86/code_x86.d#L299

which relies on `union evc`:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/code.d#L43

which also "unionizes" pointers and values.

That pretty much covers the backend.

Nevertheless, I still have been creating PRs that replace other unsafe 
constructs, like replacing pointers to arrays with D arrays, and replacing 
pointers to single objects with references. (This is why I wanted the ref DIP 
implemented, but I have to delay using it until the bootstrap compiler supports
it.)

The problem with the front end is different. It's problem is the lack of
leaves! 
Due to the use of lazy semantic analysis, the compiler is very recursive. You 
can't make one function  safe without simultaneously making every function in 
the cycles  safe. Detouring through  trusted is the only practical path forward 
with that.

Another issue is the use of printf and its buddies. I've proposed ways of
making 
printf  safe, but you've objected to them. There are several ways of making it 
 safe, and it's reasonable to do them, but I always run into protests :-)

(To clarify, I am not proposing to make printf itself safe, only making calls
to 
printf safe by adjusting its format string, and flagging unsafe use of it.)
Jul 13
parent reply Dennis <dkorpel gmail.com> writes:
On Saturday, 13 July 2024 at 18:56:49 UTC, Walter Bright wrote:

 Another issue is the use of printf and its buddies. I've 
 proposed ways of making printf  safe, but you've objected to 
 them. There are several ways of making it  safe, and it's 
 reasonable to do them, but I always run into protests :-)

 (To clarify, I am not proposing to make printf itself safe, 
 only making calls to printf safe by adjusting its format 
 string, and flagging unsafe use of it.)


I need a link to that proposal and the rejections.
Jul 13
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/13/2024 12:02 PM, Dennis wrote:

 I need a link to that proposal and the rejections.


Let's take this to d.d.ideas
Jul 13
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
Dennis kirjoitti 13.7.2024 klo 20.16:

 On Thursday, 11 July 2024 at 16:26:59 UTC, Walter Bright wrote:

 The way to do it incrementally is to start by labeling each function 
  trusted, then making them  safe one by one.

 I've done this, it works.


 
 I know you've done the first part, because there's now 1122 ` trusted` 
 functions in  dmd.backend. Many of them have an unsafe interface such as:
 
 ```D
  trusted
 void list_delete(list_t list) { free(list); }
 ```
 
 Not much actual ` safe` code has come from it unfortunately.
 


Why in the world Walter did that?

He has complained that lambdas like `( trusted { list.list_delete(); 
})()` are a bad practice, since they hide the fact a ` safe` function is 
actually calling unsafe functions. But isn't this much worse? Not only 
are ` safe` functions calling unsafe functions, there isn't even a 
` trusted` in the function body to warn about the fact!

I'd have expected Walter to mark the calling functions ` trusted` 
instead, if he feels the lambda trick is too dangerous.
Jul 14
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/14/2024 6:34 AM, Dukc wrote:

 He has complained that lambdas like `( trusted { list.list_delete(); })()` are
a 
 bad practice, since they hide the fact a ` safe` function is actually calling 
 unsafe functions. But isn't this much worse? Not only are ` safe` functions 
 calling unsafe functions, there isn't even a ` trusted` in the function body
to 
 warn about the fact!
 
 I'd have expected Walter to mark the calling functions ` trusted` instead, if
he 
 feels the lambda trick is too dangerous.


It wasn't just me. Quite a few people realized that the  trusted lambda
approach 
did not work.
Jul 24
parent reply Dukc <ajieskola gmail.com> writes:
Walter Bright kirjoitti 25.7.2024 klo 5.12:

 On 7/14/2024 6:34 AM, Dukc wrote:
 
 It wasn't just me. Quite a few people realized that the  trusted lambda 
 approach did not work.
 


I'm not denying the trusted lambda trick has it's downsides, and it's 
often better to just mark the whole calling function ` trusted`.

What I fail to see is why would marking the *called* function 
` trusted`, when it's API is actually unsafe, be any better than the 
lambda trick? All the issues that make the lambda trick bad still apply, 
only worse.
Jul 26
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2024 10:11 AM, Dukc wrote:

 What I fail to see is why would marking the *called* function ` trusted`, when 
 it's API is actually unsafe, be any better than the lambda trick? All the
issues 
 that make the lambda trick bad still apply, only worse.


I've answered that question probably a dozen times here.
Jul 28
parent Dukc <ajieskola gmail.com> writes:
Walter Bright kirjoitti 28.7.2024 klo 21.12:

 On 7/26/2024 10:11 AM, Dukc wrote:

 What I fail to see is why would marking the *called* function 
 ` trusted`, when it's API is actually unsafe, be any better than the 
 lambda trick? All the issues that make the lambda trick bad still 
 apply, only worse.


 
 I've answered that question probably a dozen times here.


Right, you wrote that ` trusted` serves as your greppable todo list (as 
opposed to a comment or UDA most of us would use for that purpose). I 
quess ` trusted` lambdas wouldn't do (nor marking the calling function 
` trusted`) as the permanent solution if that's the case.

This can actually work in in one particular case: If you're going to 
make the module in question 100% ` safe`. This means no pointer 
arithmetic, no manually freeing memory, no typecasting. You're known for 
your willingness to use unconventional low level tricks to speed up the 
compiler. Are you really ready to get rid of everything that isn't 
allowed in ` safe`, or failing that, to push such code to another module 
where there will be no temporary safewashing?

If you are, you can actually demonstrate it! Given you've accepted the 
need to make everything in `dmd/backend/dlist.d` ` safe` in the long 
term, there is at least one long-term solution for `list_delete(list_t)` 
that you would accept. What would that be?
Jul 28
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 11 July 2024 at 16:26:59 UTC, Walter Bright wrote:

 On 7/9/2024 8:58 AM, Nick Treleaven wrote:

 Any pattern to subvert safe involves the ` trusted` attribute 
 (except for compiler bugs, which editions help to fix). 
 ` trusted` is an obvious flag in code review that 
 memory-safety may be violated. Grepping for ` trusted` is an 
 easy way to narrow down places where memory-safety is violated.
 
 Arguing that  trusted can be abused is a tiny problem compared 
 to the far harder to detect abuse in  system by default code.


 That's right. Converting an entire program to  safe can be done 
 successfully by doing it incrementally, getting it to pass its 
 test suite at each step. The way to do it incrementally is to 
 start by labeling each function  trusted, then making them 
  safe one by one.

 I've done this, it works.

 And, as you observe, grepping for " trusted" makes for a 
 builtin-in TODO list!


This is not the right approach. You start with marking things 
` safe` that are leaves, and then move up. Leave things as 
` system` until you can mark them as ` safe`.

And all templates should be unmarked.

Marking everything ` trusted` at first is just going to end in 
disaster.

When I converted mysql-native to have a ` safe` interface, I 
would start by marking the module ` safe:` at the top, and see 
what breaks. Then I would mark code ` system` that was not safe, 
and see if I could massage it into being ` safe`. I never marked 
anything ` trusted` unless I could prove that it had a safe 
interface.

In some cases, marking ` safe:` at the top does work! But it 
needs to be [a module with no templates in 
it](https://github.com/mysql-d/mysql-native/blob/57fbc2b61aa93dccc11b2f45d3ae23552fd1fdff/source/mysql/imp
/connection.d#L32). In many cases, after finding all the safety problems, I had
to mark selective pieces as ` safe`.

In my case, the largest problem with my code was using `Variant` 
which cannot be safe. I sure as hell could not mark all of 
variant trusted, as it's in Phobos, and it's also *not safe*.

Another problem with marking ` safe:` at the top, and bludgeoning 
your way through with ` trusted` marks is that you will end up 
marking actual ` system` code as ` trusted`, when it doesn't need 
to be. You only need the *edge* of the safety barrier to be 
marked as trusted.

And finally, if you mark everything trusted, and then find out 
later "oh, this actually cannot be made safe", then all of a 
sudden you might have to mark it as system, and now it cascades 
to a bunch of other things that you thought were already marked 
safe, and now those have to be marked system, and so on. Worst 
case scenario, you have external code depending on the 
trustedness, and now you break other people's code!

My recommendation is to use ` safe:` at the top to *find* where 
you need to address safety problems, and then handle one item at 
a time, marking ` safe`, ` trusted` or ` system` as appropriate. 
Then remove the top line (if it's not all safe).

-Steve
Jul 13
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Those are good suggestions, but I've been trying to make dmd  safe now for a 
while. With all the inheritance going on, and the flow graph cycles, your 
suggestions are not workable.

For programs that have an acyclical graph, and little inheritance, your 
suggestions are more tractable.

Just making `toChars()` safe has turnout to be a major undertaking.
Jul 15
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/15/24 20:24, Walter Bright wrote:

 Those are good suggestions, but I've been trying to make dmd  safe now 
 for a while. With all the inheritance going on, and the flow graph 
 cycles, your suggestions are not workable.
 


What I suggested is in fact workable even for code with a big cyclical 
call graph.
Jul 17
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2024 12:17 PM, Timon Gehr wrote:

 On 7/15/24 20:24, Walter Bright wrote:

 Those are good suggestions, but I've been trying to make dmd  safe now for a 
 while. With all the inheritance going on, and the flow graph cycles, your 
 suggestions are not workable.


 
 What I suggested is in fact workable even for code with a big cyclical call
graph.



I am not understanding how.
Jul 19
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/19/24 20:10, Walter Bright wrote:

 On 7/17/2024 12:17 PM, Timon Gehr wrote:

 On 7/15/24 20:24, Walter Bright wrote:

 Those are good suggestions, but I've been trying to make dmd  safe 
 now for a while. With all the inheritance going on, and the flow 
 graph cycles, your suggestions are not workable.


 What I suggested is in fact workable even for code with a big cyclical 
 call graph.


 
 
 I am not understanding how.


You are marking functions as `pragma(local_safe)` one by one while you 
fix any errors that pop up. The code remains compilable for the entire 
time. Then once the entire cycle has been fixed, you can replace 
`pragma(local_safe)` by ` safe`.

I guess in practice you'd want some ` system` calls to be flagged while 
you port, but not others, so some design work may still be needed.

In any case, if I had to port a big codebase to ` safe`, it is likely I 
would just fork the compiler and create some tooling to help with the job.
Jul 20
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2024 9:10 AM, Timon Gehr wrote:

 You are marking functions as `pragma(local_safe)` one by one while you fix any 
 errors that pop up. The code remains compilable for the entire time. Then once 
 the entire cycle has been fixed, you can replace `pragma(local_safe)` by
` safe`.


How is that different from marking with  trusted?
Jul 22
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/22/24 18:51, Walter Bright wrote:

 On 7/20/2024 9:10 AM, Timon Gehr wrote:

 You are marking functions as `pragma(local_safe)` one by one while you 
 fix any errors that pop up. The code remains compilable for the entire 
 time. Then once the entire cycle has been fixed, you can replace 
 `pragma(local_safe)` by ` safe`.


 
 How is that different from marking with  trusted?
 


It will not make the function callable from properly ` safe` code yet, 
it will just enable some checks. There could be another `pragma` (e.g., 
`pragma(local_safe, false)` to silence the checks for some portion of 
the function.

This way you can gradually enable checks without introducing safety lies 
into the type system. Once all the checks pass, memory safety has been 
established and you can mark the functions properly ` safe`.

Maybe `pragma(check_safe)` that checks the entire body, even function 
calls, would be more useful on its own, but we could easily have both.

Anyway, the point is there should be a way to have the compiler help you 
do this kind of safety scaffolding without you needing to lie to the 
compiler.
Jul 22
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/22/2024 12:00 PM, Timon Gehr wrote:

 Anyway, the point is there should be a way to have the compiler help you do
this 
 kind of safety scaffolding without you needing to lie to the compiler.


I understand your design and it has merit.

Issues:

1. the proliferation of these features. Have you seen all the C extensions VC 
and gcc have? It makes for an excessively large and intimidating language. The 
larger the specification, the less people will read it.

2. if an existing feature can be pressed into service instead, adding a new 
feature needs a big advantage

3. one of the earliest goals with D was to make it easier for managers and QA 
staff to have rules and enforce them.  trusted was always intended to be an 
easily greppable construct so that the QA reviewer knows where to focus his 
effort. A manager can lay down a rule "no level1 programmers can check in 
 trusted" and enforce it mechanically.

4.  trusted makes for a nice and easily grepped TODO list to measure progress
on 
making the code actually safe

5. In a final release,  trusted should be quite rare. But it's up to the team
to 
enforce it.

6.  trusted can absolutely be abused. But you can't hide it!

7. Simple is better.

8. Not needing to learn new things is better.
Jul 24
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/25/24 04:32, Walter Bright wrote:

 On 7/22/2024 12:00 PM, Timon Gehr wrote:

 Anyway, the point is there should be a way to have the compiler help 
 you do this kind of safety scaffolding without you needing to lie to 
 the compiler.


 
 I understand your design and it has merit.
 
 Issues:
 
 1. the proliferation of these features. Have you seen all the C 
 extensions VC and gcc have? It makes for an excessively large and 
 intimidating language. The larger the specification, the less people 
 will read it.
 ...


Hardly applies in any relevant fashion to pragmas that enable additional 
type checking.


 2. if an existing feature can be pressed into service instead, adding a 
 new feature needs a big advantage
 ...


You are in effect removing an existing feature.


 3. one of the earliest goals with D was to make it easier for managers 
 and QA staff to have rules and enforce them.  trusted was always 
 intended to be an easily greppable construct so that the QA reviewer 
 knows where to focus his effort. A manager can lay down a rule "no 
 level1 programmers can check in  trusted" and enforce it mechanically.
 ...


Well, your approach is essentially that your higher-level programmers go 
around slapping ` trusted:` on files. I'll give you that banning "level1 
programmers" from checking in any code at all probably does help safety.


 4.  trusted makes for a nice and easily grepped TODO list to measure 
 progress on making the code actually safe
 ...


No, some uses of ` trusted` are inevitable. ` trusted` means: "this has 
been audited and the author certifies that the interface is safe".

What you are describing is not ` trusted`, you are describing ` yolo`: 
"this has not been audited at all but I need it to be ` safe` anyway for 
marketing purposes".


 5. In a final release,  trusted should be quite rare. But it's up to the 
 team to enforce it.
 ...


Well, what do you think I am doing here? You are behaving in a way I 
deem irresponsible by promoting this way of using ` trusted`.


 6.  trusted can absolutely be abused. But you can't hide it!
 ...


I am putting forward a critique of that abuse, which is indeed plainly 
visible.


 7. Simple is better.
 ...


Apparently ` trusted` is already too complex for most people to wrap 
their heads around it. It's a pity.


 8. Not needing to learn new things is better.


The way you suggest ` trusted` should be used is a novelty. It's a 
completely new attribute.
Jul 25
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 25 July 2024 at 11:47:21 UTC, Timon Gehr wrote:

 On 7/25/24 04:32, Walter Bright wrote:

 On 7/22/2024 12:00 PM, Timon Gehr wrote:

 Anyway, the point is there should be a way to have the 
 compiler help you do this kind of safety scaffolding without 
 you needing to lie to the compiler.


 
 I understand your design and it has merit.
 
 Issues:
 
 1. the proliferation of these features. Have you seen all the 
 C extensions VC and gcc have? It makes for an excessively 
 large and intimidating language. The larger the specification, 
 the less people will read it.
 ...


 Hardly applies in any relevant fashion to pragmas that enable 
 additional type checking.


 2. if an existing feature can be pressed into service instead, 
 adding a new feature needs a big advantage
 ...


 You are in effect removing an existing feature.


 3. one of the earliest goals with D was to make it easier for 
 managers and QA staff to have rules and enforce them.  trusted 
 was always intended to be an easily greppable construct so 
 that the QA reviewer knows where to focus his effort. A 
 manager can lay down a rule "no level1 programmers can check 
 in  trusted" and enforce it mechanically.
 ...


 Well, your approach is essentially that your higher-level 
 programmers go around slapping ` trusted:` on files. I'll give 
 you that banning "level1 programmers" from checking in any code 
 at all probably does help safety.


 4.  trusted makes for a nice and easily grepped TODO list to 
 measure progress on making the code actually safe
 ...


 No, some uses of ` trusted` are inevitable. ` trusted` means: 
 "this has been audited and the author certifies that the 
 interface is safe".

 What you are describing is not ` trusted`, you are describing 
 ` yolo`: "this has not been audited at all but I need it to be 
 ` safe` anyway for marketing purposes".


 5. In a final release,  trusted should be quite rare. But it's 
 up to the team to enforce it.
 ...


 Well, what do you think I am doing here? You are behaving in a 
 way I deem irresponsible by promoting this way of using 
 ` trusted`.


 6.  trusted can absolutely be abused. But you can't hide it!
 ...


 I am putting forward a critique of that abuse, which is indeed 
 plainly visible.


 7. Simple is better.
 ...


 Apparently ` trusted` is already too complex for most people to 
 wrap their heads around it. It's a pity.


 8. Not needing to learn new things is better.


 The way you suggest ` trusted` should be used is a novelty. 
 It's a completely new attribute.


I totally agree with Timon here.

Lately I was speaking with a friend of mine, now a senior Nvidia 
manager, curious about what programming language we are using in 
DeepGlance as I claimed we care for memory safety. Guess what he 
should think about this thread, after having pointed it to

https://dlang.org/spec/memory-safe-d.html
" trusted functions __MUST__ have a safe interface"

when he could see the language main author writing: ` trusted 
void list_delete(list_t list) { free(list); }`, advocating to 
slap trusted everywhere?

How you can think someone can just expose himself in advising D 
stating that??

I understand the problem you put on the table, but that MUST be 
solved with a new greppable attribute or a pragma, abusing 
 trusted. There's no plan B.

/P
Jul 25
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:

 I understand the problem you put on the table, but that MUST be 
 solved with a new greppable attribute or a pragma, abusing 
  trusted. There's no plan B.


... NOT abusing  truested  ...
Jul 25
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
How can Rust be safe if programmers can just slap on the "unsafe" attribute?
Jul 25
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/25/24 19:09, Walter Bright wrote:

 How can Rust be safe


Rust is indeed a memory-unsafe language. Yet better memory safety is one 
of its key features.

Rust had its share of controversy over popular libraries with memory 
safety bugs. However, those were unintentional.

Also:

https://github.com/rust-lang/rust/labels/I-unsound
https://github.com/rust-lang/rust/issues/25860 (open since 2015)
https://github.com/Speykious/cve-rs


 if programmers can just slap on the "unsafe" attribute?
 


(The "unsafe" attribute is not a memory safety problem. Lack of the 
"unsafe" attribute on a function with a memory-unsafe interface is.)

It's a question of the community culture. Do Rust programmers _actually_ 
put "unsafe" blocks everywhere, carelessly? This is exactly what this is 
about.

I am taking issue with throwing overboard even the aspiration of memory 
safety. You won't get D widely recognized as a safer language if its 
ecosystem is actively encouraged to build on careless ` trusted` 
slapping-on, even on functions where it is completely obvious that they 
have an unsafe interface.
Jul 25
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 25 July 2024 at 19:36:13 UTC, Timon Gehr wrote:


 I am taking issue with throwing overboard even the aspiration 
 of memory safety. You won't get D widely recognized as a safer 
 language if its ecosystem is actively encouraged to build on 
 careless ` trusted` slapping-on, even on functions where it is 
 completely obvious that they have an unsafe interface.


This!
Jul 26
parent reply Guillaume Piolat <guillaume.piolat gmail.com> writes:
On Friday, 26 July 2024 at 08:43:19 UTC, Paolo Invernizzi wrote:

 On Thursday, 25 July 2024 at 19:36:13 UTC, Timon Gehr wrote:


 I am taking issue with throwing overboard even the aspiration 
 of memory safety. You won't get D widely recognized as a safer 
 language if its ecosystem is actively encouraged to build on 
 careless ` trusted` slapping-on, even on functions where it is 
 completely obvious that they have an unsafe interface.


 This!


Not really big on  safe (where is the RoI???? where are the 
products that beat the competition by being safe), but when 
currently used  trusted has 2 different semantic meanings:

1 -  trusted that means "I've audited that the  system function I 
call are memoy-safe. do not grep this, there is nothing to see"
2 -  trusted that means "TODO, this is necessary because I've 
slapped  safe on top and must go on with productive things. I'll 
get back later! I should have marked this  system in the first 
place. I promise i'll get back and fix it!!1"
Jul 26
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 26 July 2024 at 14:59:52 UTC, Guillaume Piolat wrote:

 On Friday, 26 July 2024 at 08:43:19 UTC, Paolo Invernizzi wrote:



 Not really big on  safe (where is the RoI???? where are the 
 products that beat the competition by being safe)


https://www.adacore.com/uploads/techPapers/222559-adacore-nvidia-case-study-v5.pdf


, but when
 currently used  trusted has 2 different semantic meanings:

 1 -  trusted that means "I've audited that the  system function 
 I call are memoy-safe. do not grep this, there is nothing to 
 see"
 2 -  trusted that means "TODO, this is necessary because I've 
 slapped  safe on top and must go on with productive things. 
 I'll get back later! I should have marked this  system in the 
 first place. I promise i'll get back and fix it!!1"


The second one is safe washing. If we need this as an aid tool 
during development it should not be a mere "comment" on code, but 
something that the compiler can enforce: in Elm for example, that 
we are using as a frontend, the compiler complains if you try to 
build a release versione of the code and you have not removed 
things that should not appear in a release.
Jul 26
prev sibling next sibling parent Jordan Wilson <wilsonjord gmail.com> writes:
On Friday, 26 July 2024 at 14:59:52 UTC, Guillaume Piolat wrote:

 On Friday, 26 July 2024 at 08:43:19 UTC, Paolo Invernizzi wrote:

 On Thursday, 25 July 2024 at 19:36:13 UTC, Timon Gehr wrote:


 [...]


 This!


 Not really big on  safe (where is the RoI???? where are the 
 products that beat the competition by being safe), but when 
 currently used  trusted has 2 different semantic meanings:

 1 -  trusted that means "I've audited that the  system function 
 I call are memoy-safe. do not grep this, there is nothing to 
 see"
 2 -  trusted that means "TODO, this is necessary because I've 
 slapped  safe on top and must go on with productive things. 
 I'll get back later! I should have marked this  system in the 
 first place. I promise i'll get back and fix it!!1"


This was my initial thoughts as well, almost like needing 
 unverified.
Jul 26
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 7/26/24 16:59, Guillaume Piolat wrote:


 
 Not really big on  safe (where is the RoI????


Well, I am perfectly fine with people just not using ` safe`. However, 
when I actually want some dependency to be ` safe` because it has to 
deal with potentially adversarial input, I'd prefer if the author 
actually took some care to make the interface solid.


 where are the products that beat the competition by being safe),


Then why would you even care to lie to prospective users? Just don't use 
` safe` at that point.


 but when currently used  trusted has 2 different semantic meanings:
 
 1 -  trusted that means "I've audited that the  system function I call 
 are memoy-safe.


This is what it's being advertised as.


 do not grep this, there is nothing to see"


You can still grep to see if you agree with the assessment.


 2 -  trusted that means "TODO, this is necessary because I've slapped 
  safe on top and must go on with productive things. I'll get back later! 
 I should have marked this  system in the first place. I promise i'll get 
 back and fix it!!1"


What is even the point? If you think maintaining a memory-safe interface 
is a waste of time and a non-feature, something that nobody actually 
needs, don't even attempt to do it.

Either ` safe` is a feature we want in the language, then it should be 
solid, or we'd be better off just removing it. What I am not on board 
with is making ` safe` a priority while at the same time abandoning 
memory safety in ` safe` code. This makes no sense.



 Jul 28



 next sibling parent reply Don Allen <donaldcallen gmail.com>  writes:


On Sunday, 28 July 2024 at 14:25:14 UTC, Timon Gehr wrote:

 On 7/26/24 16:59, Guillaume Piolat wrote:


 
 Not really big on  safe (where is the RoI????


 Well, I am perfectly fine with people just not using ` safe`. 
 However, when I actually want some dependency to be ` safe` 
 because it has to deal with potentially adversarial input, I'd 
 prefer if the author actually took some care to make the 
 interface solid.


 where are the products that beat the competition by being 
 safe),


 Then why would you even care to lie to prospective users? Just 
 don't use ` safe` at that point.


 but when currently used  trusted has 2 different semantic 
 meanings:
 
 1 -  trusted that means "I've audited that the  system 
 function I call are memoy-safe.


 This is what it's being advertised as.


 do not grep this, there is nothing to see"


 You can still grep to see if you agree with the assessment.


 2 -  trusted that means "TODO, this is necessary because I've 
 slapped  safe on top and must go on with productive things. 
 I'll get back later! I should have marked this  system in the 
 first place. I promise i'll get back and fix it!!1"


 What is even the point? If you think maintaining a memory-safe 
 interface is a waste of time and a non-feature, something that 
 nobody actually needs, don't even attempt to do it.

 Either ` safe` is a feature we want in the language, then it 
 should be solid, or we'd be better off just removing it. What I 
 am not on board with is making ` safe` a priority while at the 
 same time abandoning memory safety in ` safe` code. This makes 
 no sense.


I'm guessing that your issue with all of this talk about memory 
safety is that you have no sense of a coherent plan. If I'm 
right, then I share your concern. This is not intended as a 
criticism of Walter, because I see defining and enforcing memory 
safety in D as a very hard problem, so it doesn't surprise me 
that a clear plan isn't apparent.

I think the difficulty is that D has its roots in C and C++, both 
notably memory-unsafe. D adds the garbage collector to the mix of 
stack- and manually-heap-allocated memory. Trying to provide 
compiler-enforced guarantees in the face of these disparate 
options is not a simple matter. Reading the "Function Safety" 
section of the language reference made my head spin. I think its 
complexity flows directly from the memory-management options D 
provides.

Rust avoids this problem by providing a single memory-management 
methodology that is imposed on the user. There are no choices. 
You do it the Rust way or your code won't compile.

I personally like that D offers the choices it does and in my own 
code, I avoid malloc/free and use of pointers as much as 
possible. I stack-allocate when feasible and GC-allocate when 
necessary. Talking to C code complicates things, something that 
bit me when I was first learning D (I passed a GC-allocated 
string to sqlite as a binding and failed to read the warning in 
the toStringz documentation about the string vaporizing in a 
subsequent garbage collection).

My own preference would be to first focus on improving the 
documentation of what is already in the language. What types get 
stack-allocated? GC-allocated? It's not always clear in the 
current documentation, e.g., I believe static arrays are 
stack-allocated; where does it say that? There are many other 
examples of this information not present in the documentation. 
The programmer needs to know this information to avoid unsafe 
memory-management practices, because what is required of the 
programmer depends upon the type of memory in question.

I think one of the great features of D is the ability of D and C 
code to talk directly without the need for an intermediate 
interface. The current documentation is a good start, but could 
be improved with more explanation and examples of how to this 
safely.

I think improved documentation would help to make people happier 
with D. I don't think D needs to be compiler-guaranteed memory 
safe, which is good because I don't think it's possible. There 
may be opportunities for the compiler to provide *some* help in 
this area that it presently doesn't, but I doubt that D will ever 
be able to make the assertions about memory-safety that Rust 
does. Note that Zig provides only stack- and manual 
heap-allocation. It is not a memory-safe language. But there's a 
lot of interest in it, despite not being close to release and a 
growing issue list.



 Jul 28



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


On 7/28/24 18:12, Don Allen wrote:

 ...

 Either ` safe` is a feature we want in the language, then it should be 
 solid, or we'd be better off just removing it. What I am not on board 
 with is making ` safe` a priority while at the same time abandoning 
 memory safety in ` safe` code. This makes no sense.


 
 I'm guessing that your issue with all of this talk about memory safety 
 is that you have no sense of a coherent plan.


It's more that I do have a sense of a coherent plan, but the way Walter 
abuses ` trusted` undercuts that plan as well as all existing 
documentation and articles.


 If I'm right, then I share 
 your concern. This is not intended as a criticism of Walter, because I 
 see defining and enforcing memory safety in D as a very hard problem, so 
 it doesn't surprise me that a clear plan isn't apparent.
 ...


Well, I think it's pretty clear what the story is:

- ` safe` means memory safe.
- ` system` means potentially not memory safe.
- ` trusted` means memory safe, but the compiler is not asked to check it.

` safe` is unfinished, and still leaves open some holes. DIP1000 
addresses most of these, but is also still work in progress.

The main reason why ` safe` is hard is that quite a few people, most 
importantly Walter, want it to be expressive. DIP1000 is already harder 
than ` safe` needs to be. The simplest possible definition of ` safe` 
is: just use the GC. This was Robert's point at last years DConf: "Why 
are you even taking references to stack memory in  safe?"

` safe` D is not hard because it has to be, it is hard because of 
concerns about expressiveness.

An issue with ` safe`/` system`/` trusted` is that it is not 
fine-grained enough and does not give the programmer enough control over 
safety checks. This is one of the reasons why people are abusing ` trusted`.


 I think the difficulty is that D has its roots in C and C++, both 
 notably memory-unsafe. D adds the garbage collector to the mix of stack- 
 and manually-heap-allocated memory. Trying to provide compiler-enforced 
 guarantees in the face of these disparate options is not a simple 
 matter. Reading the "Function Safety" section of the language reference 
 made my head spin. I think its complexity flows directly from the 
 memory-management options D provides.
 ...


Well, it is possible to simply disallow some of those options in ` safe` 
code.


 Rust avoids this problem by providing a single memory-management 
 methodology that is imposed on the user. There are no choices. You do it 
 the Rust way or your code won't compile.
 ...


I mean, not really. You can manipulate raw pointers to stack-allocated 
memory in Rust too, it just will not be safe.
https://doc.rust-lang.org/std/ptr/index.html
https://doc.rust-lang.org/reference/unsafe-keyword.html

It's quite similar really:

- ` safe` corresponds to a Rust function that is not unsafe and has no 
unsafe blocks in it.
- ` trusted` corresponds to a Rust function that is not unsafe and has a 
single big unsafe block in it.
- ` system` corresponds to a Rust function that is unsafe and has a 
single big unsafe block in it.


The only question is how the type system and language semantics are 
defined, which will influence what kind of code can be written in the 
safe subset. Rust dedicates a bit more type system real estate to static 
lifetime analysis, D's DIP1000 is more restrictive.

I.e., there is nothing magic about Rust that is not already in D in 
terms of how memory safety works at the very basic level. This includes 
unsoundness bugs in the type checker.


 I personally like that D offers the choices it does and in my own code, 
 I avoid malloc/free and use of pointers as much as possible. I 
 stack-allocate when feasible and GC-allocate when necessary. Talking to 
 C code complicates things, something that bit me when I was first 
 learning D (I passed a GC-allocated string to sqlite as a binding and 
 failed to read the warning in the toStringz documentation about the 
 string vaporizing in a subsequent garbage collection).
 
 My own preference would be to first focus on improving the documentation 
 of what is already in the language. What types get stack-allocated? 
 GC-allocated? It's not always clear in the current documentation, e.g., 
 I believe static arrays are stack-allocated; where does it say that?


They are allocated wherever you put them, because they are value types:
https://dlang.org/spec/arrays.html#static-arrays

Documentation can always be improved, but the distinction between value 
types and reference types I think is made pretty clear by the 
documentation on structs and classes.


 There are many other examples of this information not present in the 
 documentation. The programmer needs to know this information to avoid 
 unsafe memory-management practices, because what is required of the 
 programmer depends upon the type of memory in question.
 ...


Local variables are usually stack-allocated, except when there's a 
closure, then they are allocated on the heap. Explicit allocations go 
wherever the allocator puts them.


 I think one of the great features of D is the ability of D and C code to 
 talk directly without the need for an intermediate interface. The 
 current documentation is a good start, but could be improved with more 
 explanation and examples of how to this safely.
 
 I think improved documentation would help to make people happier with D.
 I don't think D needs to be compiler-guaranteed memory safe, which is 
 good because I don't think it's possible.


Compiler guarantees are not really the issue at hand at the moment. The 
issue is that Walter advocated for marking functions memory safe that 
are not memory safe. It's the ultimate middle finger to people who care 
about documentation, especially documentation that is embedded into the 
function signature.


 There may be opportunities for 
 the compiler to provide *some* help in this area that it presently 
 doesn't, but I doubt that D will ever be able to make the assertions 
 about memory-safety that Rust does.


Rust will never be able to make the assertions about memory safety that 
people seem to think Rust makes about memory safety.

Anyway, D it already makes the assertion that ` safe` means memory safe, 
and it is in much better shape than Rust a priori in terms of memory 
safety because of the garbage collector.

It is quite annoying to me that people just go "memory safe"? That must 
mean like Rust. Nope. Why does nobody ever bring up Java?


 Note that Zig provides only stack- 
 and manual heap-allocation. It is not a memory-safe language. But 
 there's a lot of interest in it, despite not being close to release and 
 a growing issue list.


I think they are doing some interesting things, but it is not for me.



 Jul 28



 next sibling parent reply Don Allen <donaldcallen gmail.com>  writes:


On Sunday, 28 July 2024 at 18:21:41 UTC, Timon Gehr wrote:

 On 7/28/24 18:12, Don Allen wrote:

 ...




[snip]

 I mean, not really. You can manipulate raw pointers to 
 stack-allocated memory in Rust too, it just will not be safe.


I was talking about 'safe' Rust. I thought that was obvious. 
Apparently not.

[snip}

 Rust will never be able to make the assertions about memory 
 safety that people seem to think Rust makes about memory safety.


I don't think there's any doubt about the assertions Rust makes 
about memory safety in code that does not have the word 'unsafe' 
anywhere. Are you saying that they are lying?


 Anyway, D it already makes the assertion that ` safe` means 
 memory safe, and it is in much better shape than Rust a priori 
 in terms of memory safety because of the garbage collector.

 It is quite annoying to me that people just go "memory safe"? 
 That must mean like Rust. Nope. Why does nobody ever bring up 
 Java?


Or Lisp/Scheme?


 Note that Zig provides only stack- and manual heap-allocation. 
 It is not a memory-safe language. But there's a lot of 
 interest in it, despite not being close to release and a 
 growing issue list.


 I think they are doing some interesting things, but it is not 
 for me.


That's completely irrelevant. The point is that Zig is not 
memory-safe and still has attracted great interest. Some are even 
using it, prematurely.



 Jul 28



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


On 7/28/24 20:51, Don Allen wrote:

 On Sunday, 28 July 2024 at 18:21:41 UTC, Timon Gehr wrote:

 On 7/28/24 18:12, Don Allen wrote:

 ...




 [snip]

 I mean, not really. You can manipulate raw pointers to stack-allocated 
 memory in Rust too, it just will not be safe.


 
 I was talking about 'safe' Rust. I thought that was obvious. Apparently 
 not.
 ...


It seemed to me like you were contrasting safe Rust with full D, while 
at the same time buying Rust's safety marketing, but not the one of 
 safe D, when they are actually largely similar.


 [snip}

 Rust will never be able to make the assertions about memory safety 
 that people seem to think Rust makes about memory safety.


 
 I don't think there's any doubt about the assertions Rust makes about 
 memory safety in code that does not have the word 'unsafe' anywhere.


In the real world, systems that have not been formally verified 
typically have some flaws. If you don't have doubts, question why that is.


 Are you saying that they are lying?
 ...


They are not lying about their aspirations, I assume, but the reality is 
indeed not quite there:
https://github.com/Speykious/cve-rs

In any case, my point was more that people seem to hype safe Rust and 
you were comparing that hype to a somewhat overly skeptical view of D. 
This is not an apples to apples comparison.


 Anyway, D it already makes the assertion that ` safe` means memory 
 safe, and it is in much better shape than Rust a priori in terms of 
 memory safety because of the garbage collector.

 It is quite annoying to me that people just go "memory safe"? That 
 must mean like Rust. Nope. Why does nobody ever bring up Java?


 
 Or Lisp/Scheme?
 ...


Even better.


 Note that Zig provides only stack- and manual heap-allocation. It is 
 not a memory-safe language. But there's a lot of interest in it, 
 despite not being close to release and a growing issue list.


 I think they are doing some interesting things, but it is not for me.


 
 That's completely irrelevant. The point is that Zig is not memory-safe 
 and still has attracted great interest.


D and Rust are not memory safe either and also have attracted great 
interest.


 Some are even using it, prematurely.


Software today is still in a general state of immaturity, and 
programming language design is part of that.

Anyway, personally I do not really care about popularity as an indicator 
of relevance. I guess the lead designer is opinionated and charismatic. 
I'm sure he's even right about some things. If they want to re-learn 
some of the lessons that came out of C, up to them.

Also, not everyone's focus has to be the same, and I guess they chose to 
focus on improving tooling and other aspects of language design.

In the case of D, Walter has laid down making  safe D work well as a 
priority. You can of course question that, but this is what the coherent 
plan is. (Or used to be until Walter's recent takes on ` trusted`.)



 Jul 29



  parent  Don Allen <donaldcallen gmail.com>  writes:


On Monday, 29 July 2024 at 14:05:47 UTC, Timon Gehr wrote:

 On 7/28/24 20:51, Don Allen wrote:

 On Sunday, 28 July 2024 at 18:21:41 UTC, Timon Gehr wrote:

 On 7/28/24 18:12, Don Allen wrote:

 ...




 [snip]

 I mean, not really. You can manipulate raw pointers to 
 stack-allocated memory in Rust too, it just will not be safe.


 
 I was talking about 'safe' Rust. I thought that was obvious. 
 Apparently not.
 ...


 It seemed to me like you were contrasting safe Rust with full 
 D, while at the same time buying Rust's safety marketing, but 
 not the one of  safe D, when they are actually largely similar.


Not my intent at all. I was contrasting the options for memory 
management we have in D with the box (pun intended) you are in 
when using Rust.


 [snip}

 Rust will never be able to make the assertions about memory 
 safety that people seem to think Rust makes about memory 
 safety.


 
 I don't think there's any doubt about the assertions Rust 
 makes about memory safety in code that does not have the word 
 'unsafe' anywhere.




Here I was simply stating the obvious -- that we know what the 
Rust people are saying about memory safety. It was a weak attempt 
at a joke.


 In the real world, systems that have not been formally verified 
 typically have some flaws. If you don't have doubts, question 
 why that is.


 Are you saying that they are lying?
 ...


 They are not lying about their aspirations, I assume, but the 
 reality is indeed not quite there:
 https://github.com/Speykious/cve-rs


I was not aware of this -- interesting work -- but it does not 
surprise me. What Rust is trying to do is very difficult and I'm 
not surprised that it isn't perfect. This person has found edge 
cases that Rust doesn't handle. It's similar to getting on an 
airliner, which we're all told is "safe", despite the fact that 
they do crash. But would you rather go somewhere on an airliner 
or a motorcycle?

The probabilities matter. If language                             
                                                            
-assured memory safety is important to you, Rust is a  good 
choice *if* you are willing to pay the price in language 
difficulty *and* you have a real-time constraint.


 In any case, my point was more that people seem to hype safe 
 Rust and you were comparing that hype to a somewhat overly 
 skeptical view of D. This is not an apples to apples comparison.


I really don't understand how you got that from what I wrote. 
Perhaps I wasn't clear.

My intent was to say that I prefer the D way. I appreciate the 
memory-management choices D provides; I don't appreciate being 
forced to do things the Rust way, particularly in view of the 
difficulty of complying with all its rules. In D, I've found my 
own memory-management approach, using a subset of what the 
language makes available, and for the work I'm doing, writing 
safe, reliable D code (and maintaining it) has been far easier 
than the same in Rust. This is related to discussions I've had 
with Rust fans (not always cordial) in which I said that I didn't 
think the Rust GC-less approach to memory safety was worthwhile, 
because of the lack of a gc made the language so demanding, for 
writing garden-variety applications that did not have real-time 
constraints.

My concerns about D are *not* about memory management and safety 
but about its complexity, especially the parts of the language 
that feel to me like they were glued on in response to what 
others were doing. I don't want to see more such warts on the 
language. If the language can be extended to assist people to 
write safe code in ways that are natural, coherent *and* 
comprehensible (again, I cite the "Function Safety" section of 
the language document as an example of things going the wrong 
way, in my opinion), then great.



 Jul 29



prev sibling  parent reply Sebastiaan Koppe <mail skoppe.eu>  writes:


On Sunday, 28 July 2024 at 18:21:41 UTC, Timon Gehr wrote:

 ...

 The main reason why ` safe` is hard is that quite a few people, 
 most importantly Walter, want it to be expressive. DIP1000 is 
 already harder than ` safe` needs to be. The simplest possible 
 definition of ` safe` is: just use the GC. This was Robert's 
 point at last years DConf: "Why are you even taking references 
 to stack memory in  safe?"


Let me answer that question. I believe it comes in three parts:

1) Why references? To have distinct pieces of code refer to the 
same object.
2) Why on the stack? To avoid heap allocations. Not only does it 
take time to allocate (and deallocate), it can also trigger a 
garbage collection and might kill any locality you are trying to 
achieve.
3) Why in  safe? To provide a safe interface instead of footguns.

 safe isn't a pledge to never write potentially unsafe code ever 
again (e.g. just use the GC, don't do ref, etc.), instead it is 
to have the compiler check your code for safety violations and to 
allow building a safe interface around code the compiler can't 
check. (Note the second part is an enabler for more of the first.)

Why anyone would want to have references to stack memory in  safe 
is because it gives them an edge. They put in the hard work to 
provide a  safe interface because it enables more safety check, 
and, not unimportantly, they prefer that work over debugging 
memory issues.



 Jul 28



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


On 7/29/24 00:19, Sebastiaan Koppe wrote:

 On Sunday, 28 July 2024 at 18:21:41 UTC, Timon Gehr wrote:

 ...

 The main reason why ` safe` is hard is that quite a few people, most 
 importantly Walter, want it to be expressive. DIP1000 is already 
 harder than ` safe` needs to be. The simplest possible definition of 
 ` safe` is: just use the GC. This was Robert's point at last years 
 DConf: "Why are you even taking references to stack memory in  safe?"


 
 Let me answer that question. I believe it comes in three parts:
 
 1) Why references? To have distinct pieces of code refer to the same 
 object.
 2) Why on the stack? To avoid heap allocations. Not only does it take 
 time to allocate (and deallocate), it can also trigger a garbage 
 collection and might kill any locality you are trying to achieve.
 3) Why in  safe? To provide a safe interface instead of footguns.
 
  safe isn't a pledge to never write potentially unsafe code ever again 
 (e.g. just use the GC, don't do ref, etc.), instead it is to have the 
 compiler check your code for safety violations and to allow building a 
 safe interface around code the compiler can't check. (Note the second 
 part is an enabler for more of the first.)
 
 Why anyone would want to have references to stack memory in  safe is 
 because it gives them an edge. They put in the hard work to provide a 
  safe interface because it enables more safety check, and, not 
 unimportantly, they prefer that work over debugging memory issues.


I think this is a good answer. (But note that my point was just that 
 safe is not inherently very hard, it is as hard as you make it in the 
interest of expressiveness, performance, and crash safety.)



 Jul 29



prev sibling  parent  Paulo Pinto <pjmlp progtools.org>  writes:


On Sunday, 28 July 2024 at 16:12:24 UTC, Don Allen wrote:

 On Sunday, 28 July 2024 at 14:25:14 UTC, Timon Gehr wrote:

 On 7/26/24 16:59, Guillaume Piolat wrote:


 
 ....




 I think the difficulty is that D has its roots in C and C++, 
 both notably memory-unsafe. D adds the garbage collector to the 
 mix of stack- and manually-heap-allocated memory. Trying to 
 provide compiler-enforced guarantees in the face of these 
 disparate options is not a simple matter. Reading the "Function 
 Safety" section of the language reference made my head spin. I 
 think its complexity flows directly from the memory-management 
 options D provides.


Whereas the memory safe systems languages like Modula-3, Cedar, 
Oberon came from the safety first approach, and while these 
languages might not have taken over the world, their ideas are 

debating how to solve the problem.

As hinted on my previous comment, they have been catching up on 
what D had as edge, and eventually whatever is left of that edge 
won't matter for further adoption.


 ...

 Note that Zig provides only stack- and manual heap-allocation. 
 It is not a memory-safe language. But there's a lot of interest 
 in it, despite not being close to release and a growing issue 
 list.


The interest in Zig, is it being Modula-2 with a revamped syntax 
for the C crowd, with compile time metaprogramming as cherry on 
top.

Turns out there is a crowd that would already be happy if C 
provided proper strings, arrays, strong typed enumerations, and 
less error prone memory management even if still manual, like 
Modula-2 was doing in 1978.

Since WG14 has proven that isn't something they want to improve C 
on, during the last 50 years, that is where that crowd is now 
moving on. SafeC, C2, C3 ideas never caught on, Zig might, lets 
see.



 Jul 29



prev sibling  parent reply Guillaume Piolat <guillaume.piolat gmail.com>  writes:


On Sunday, 28 July 2024 at 14:25:14 UTC, Timon Gehr wrote:

 What is even the point? If you think maintaining a memory-safe 
 interface is a waste of time and a non-feature, something that 
 nobody actually needs, don't even attempt to do it.


I want to use it to find memory-safety bugs and see the foretold 
benefits, and indeed because other users of my libs may have 
untrusted inputs.

One roadblock is those two semantic meaning of  trusted.

Many libraries with large attack surface, such as codecs, use a 
kind of unsafe iterator to parse input, making most function 
system. Porting C code locks you into that  system world, and 
it's probably why people start libraries with a top-level  safe:

Now if you don't go  safe: on top-level, then yes there is only 
one semantic meaning to  trusted. I'd be happy with some other 
word, just like const_cast doesn't exist in D.



 Jul 28



  parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Sunday, 28 July 2024 at 23:20:32 UTC, Guillaume Piolat wrote:

 On Sunday, 28 July 2024 at 14:25:14 UTC, Timon Gehr wrote:

 What is even the point? If you think maintaining a memory-safe 
 interface is a waste of time and a non-feature, something that 
 nobody actually needs, don't even attempt to do it.


 I want to use it to find memory-safety bugs and see the 
 foretold benefits, and indeed because other users of my libs 
 may have untrusted inputs.

 One roadblock is those two semantic meaning of  trusted.


There's no two semantic meaning of  trusted, there's only one: 
the interface MUST be safe.
If   trusted trusted is abused for another semantic, then D 
should introduce something explicit for that other semantic, not 
poison  trusted.

/P



 Jul 29



 next sibling parent reply Dukc <ajieskola gmail.com>  writes:


Paolo Invernizzi kirjoitti 29.7.2024 klo 11.13:

 
 There's no two semantic meaning of  trusted, there's only one: the 
 interface MUST be safe.


That's what the standard says. Therefore, I agree that's what it means 
by default.

On the other hand bit of technical safewashing may the best way to go in 
exceptional cases. Say, maybe the function was earlier thought as safe 
but later on proved to have an unsafe corner case, and it was 
inpractical to remove ` trusted` right away because the function is so 
widely used. I would not outright ban a false ` trusted` in such cases, 
provided that it's clearly documented as such.

That is, if you're reading undocumented code and see a function with 
` trusted`, you can trust it's safe. So that we don't need to separately 
document "safe interface" to the genuine ` trusted` functions we write.



 Jul 29



  parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Monday, 29 July 2024 at 09:04:36 UTC, Dukc wrote:

 Paolo Invernizzi kirjoitti 29.7.2024 klo 11.13:

 
 There's no two semantic meaning of  trusted, there's only one: 
 the interface MUST be safe.


 That's what the standard says. Therefore, I agree that's what 
 it means by default.

 On the other hand bit of technical safewashing may the best way 
 to go in exceptional cases. Say, maybe the function was earlier 
 thought as safe but later on proved to have an unsafe corner 
 case, and it was inpractical to remove ` trusted` right away 
 because the function is so widely used. I would not outright 
 ban a false ` trusted` in such cases, provided that it's 
 clearly documented as such.


Are you suggesting to advertise the library as memory safe, 
knowing it's not?
Do you have an idea of the legal consequences a company can have 
in this case?

What you are describing it's a bug, a memory safety bug that must 
be for sure disclosed to customers, but closed. And thinking 
about it, the best way is to have a separate attribute to mark it 
in the code, instead of  trusted.



 That is, if you're reading undocumented code and see a function 
 with ` trusted`, you can trust it's safe. So that we don't need 
 to separately document "safe interface" to the genuine 
 ` trusted` functions we write.


That's _exactly_ the contrary of  trusted philosophy, and 
semantic. It's non-sense.



 Jul 29



  parent reply Dukc <ajieskola gmail.com>  writes:


Paolo Invernizzi kirjoitti 29.7.2024 klo 12.48:

 Are you suggesting to advertise the library as memory safe, knowing it's 
 not?
 Do you have an idea of the legal consequences a company can have in this 
 case?
 
 What you are describing it's a bug, a memory safety bug that must be for 
 sure disclosed to customers, but closed. And thinking about it, the best 
 way is to have a separate attribute to mark it in the code, instead of 
  trusted.


No. I mean (silly example but demonstrates the principle) that these are 
wrong:

```D
extern(c)  trusted void free(void*);

/// Memory safe.
extern(c)  trusted void free(void*);
```

...but this is okay:

```D
/// Warning: Not actually memory safe! Review any  safe function
/// that uses this like it was a  trusted function and warn that it has
/// unsafe code inside
extern(c)  trusted void free(void*);
```

This pattern still can't be exactly recommended, but if for some strange 
reason the function would be too inpractical to mark as ` system` it's 
still an option.



 Jul 29



  parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Monday, 29 July 2024 at 11:14:25 UTC, Dukc wrote:

 Paolo Invernizzi kirjoitti 29.7.2024 klo 12.48:

 Are you suggesting to advertise the library as memory safe, 
 knowing it's not?
 Do you have an idea of the legal consequences a company can 
 have in this case?
 
 What you are describing it's a bug, a memory safety bug that 
 must be for sure disclosed to customers, but closed. And 
 thinking about it, the best way is to have a separate 
 attribute to mark it in the code, instead of  trusted.


 No. I mean (silly example but demonstrates the principle) that 
 these are wrong:

 ```D
 extern(c)  trusted void free(void*);

 /// Memory safe.
 extern(c)  trusted void free(void*);
 ```

 ...but this is okay:

 ```D
 /// Warning: Not actually memory safe! Review any  safe function
 /// that uses this like it was a  trusted function and warn 
 that it has
 /// unsafe code inside
 extern(c)  trusted void free(void*);
 ```

 This pattern still can't be exactly recommended, but if for 
 some strange reason the function would be too inpractical to 
 mark as ` system` it's still an option.


The "review any  safe function ... like it was a  trusted 
function" is an abomination, and totally dismiss the only reason 
to have  safe in the language.

 safe: MECHANICALLY verified, it's safe, NO NEED to review.



 Jul 29



  parent reply Dukc <ajieskola gmail.com>  writes:


Paolo Invernizzi kirjoitti 29.7.2024 klo 14.21:

 
 The "review any  safe function ... like it was a  trusted function" is 
 an abomination, and totally dismiss the only reason to have  safe in the 
 language.
 
  safe: MECHANICALLY verified, it's safe, NO NEED to review.
 


It is an abomination that's pretty much only the last resort, but saying 
it totally defeats the purpose of ` safe` is exaggregation.

Consider pre-DIP1000 semantics. You can easily corrupt memory from 
` safe` code by slicing a static array on stack and returning that 
slice. Would you say that any code that isn't yet compatible with 
-dip1000 has no benefit from ` safe`?

Or consider immutable delegates. Due to language design flaws, an 
immutable delegate can have a mutable context. This breaks language 
assumptions about immutability in 100% ` safe` way. Would you say this 
defeats the purpose of ` safe` in the language?

Of course not. Those cases are incredibly annoying since they mean the 
mechanical check will fail sometimes, but you're still going to make far 
fewer memory corrupting mistakes in ` safe` code than ` system` code.

I don't see why creative use of ` trusted` is any different. Make no 
mistake, it's a game that can easily get out of hand and has to be 
highly discouraged, but it's not "do it once and you can never benefit 
from  safe".

You might object that yes, in principle you could open a hole or two and 
get away with it, but if you're doing it once you will do it again and 
again, until memory safety is a mere joke (like if you shoplift once or 
twice, you'll probably do it again and again until you get caught).

But I think it depends on why you'd do it. Done like Walter seems to be 
doing it, I agree. But there are situations where it's going to be much 
more defensible. Like the case I mentioned earlier - you have a function 
you thought was memory safe and later discover it's not, so you leave 
the ` trusted` label there for backwards compatibility (with appropriate 
warnings and a deprecation). If you do such a thing, I don't think it's 
going to make you lose your respect for memory safety in general.



 Jul 29



  parent reply bachmeier <no spam.net>  writes:


On Monday, 29 July 2024 at 12:28:33 UTC, Dukc wrote:


 I don't see why creative use of ` trusted` is any different. 
 Make no mistake, it's a game that can easily get out of hand 
 and has to be highly discouraged, but it's not "do it once and 
 you can never benefit from  safe".


This is a breaking change. ` trusted` cannot mean both "it's been 
verified" and "it's not been verified" at the same time. Doing 
this with ` trusted` means you have to assume anything with 
` trusted` hasn't been verified. If there's a desire for an 
alternative syntax to denote "I did this so it would compile" 
then that needs to be added to the language.

It's hard for me to understand how anyone can think it's a good 
idea to say the language needs a new feature so let's change an 
existing feature, break all code ever written using it, and give 
it a definition contrary to the spec. {Insert meme of vehicle 
driving over a cliff.}



 Jul 29



  parent  Dukc <ajieskola gmail.com>  writes:


bachmeier kirjoitti 29.7.2024 klo 17.06:

 On Monday, 29 July 2024 at 12:28:33 UTC, Dukc wrote:

 I don't see why creative use of ` trusted` is any different. Make no 
 mistake, it's a game that can easily get out of hand and has to be 
 highly discouraged, but it's not "do it once and you can never benefit 
 from  safe".


 
 This is a breaking change. ` trusted` cannot mean both "it's been 
 verified" and "it's not been verified" at the same time. Doing this with 
 ` trusted` means you have to assume anything with ` trusted` hasn't been 
 verified.


I think you missed my previous post. I explicitly wrote that if you have 
a function with ` trusted` and no other information about it's safety, 
you can trust it just like the spec says without verifying it.

It's only if the documentation explicitly warns the ` trusted` label is 
false when you can't do that.



 Jul 29



prev sibling  parent reply Guillaume Piolat <guillaume.piolat gmail.com>  writes:


On Monday, 29 July 2024 at 08:13:22 UTC, Paolo Invernizzi wrote:

 There's no two semantic meaning of  trusted, there's only one: 
 the interface MUST be safe.
 If   trusted trusted is abused for another semantic, then D 
 should introduce something explicit for that other semantic, 
 not poison  trusted.

 /P


It is already used that way



 Jul 29



  parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Monday, 29 July 2024 at 09:20:05 UTC, Guillaume Piolat wrote:

 On Monday, 29 July 2024 at 08:13:22 UTC, Paolo Invernizzi wrote:

 There's no two semantic meaning of  trusted, there's only one: 
 the interface MUST be safe.
 If   trusted trusted is abused for another semantic, then D 
 should introduce something explicit for that other semantic, 
 not poison  trusted.

 /P


 It is already used that way


I know, the problem is not that's already used in that way, the 
problem is that the language deus ex-machina is actively pushing 
for that.

And I think it's the final nail in the coffin for D memory safe 
credibility.



 Jul 29



  parent  Paulo Pinto <pjmlp progtools.org>  writes:


On Monday, 29 July 2024 at 09:50:56 UTC, Paolo Invernizzi wrote:

 On Monday, 29 July 2024 at 09:20:05 UTC, Guillaume Piolat wrote:

 On Monday, 29 July 2024 at 08:13:22 UTC, Paolo Invernizzi 
 wrote:

 There's no two semantic meaning of  trusted, there's only 
 one: the interface MUST be safe.
 If   trusted trusted is abused for another semantic, then D 
 should introduce something explicit for that other semantic, 
 not poison  trusted.

 /P


 It is already used that way


 I know, the problem is not that's already used in that way, the 
 problem is that the language deus ex-machina is actively 
 pushing for that.

 And I think it's the final nail in the coffin for D memory safe 
 credibility.


Indeed, otherwise for all practical purposes it is the same as 
 system, if we can't any longer trust (pun intented), that it was 
reviewed properly instead of adding  trusted to shut up the 
compiler and move on.



 Jul 29



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


On 7/25/2024 12:36 PM, Timon Gehr wrote:

 I am taking issue with throwing overboard even the aspiration of memory
safety. 
 You won't get D widely recognized as a safer language if its ecosystem is 
 actively encouraged to build on careless ` trusted` slapping-on, even on 
 functions where it is completely obvious that they have an unsafe interface.


There isn't a transition path to  safe by default unless there is a way to do
it 
incrementally.

I've done many transitions of large programs from one form to another. Doing it 
all at once does not work. It doesn't matter how hard you try. It doesn't work.



 Jul 28



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


On 7/28/24 09:02, Walter Bright wrote:

 On 7/25/2024 12:36 PM, Timon Gehr wrote:

 I am taking issue with throwing overboard even the aspiration of 
 memory safety. You won't get D widely recognized as a safer language 
 if its ecosystem is actively encouraged to build on careless 
 ` trusted` slapping-on, even on functions where it is completely 
 obvious that they have an unsafe interface.


 
 There isn't a transition path to  safe by default unless there is a way 
 to do it incrementally.
 
 I've done many transitions of large programs from one form to another. 
 Doing it all at once does not work. It doesn't matter how hard you try. 
 It doesn't work.


I am aware. If you think the consequence is that we should abuse 
` trusted` then your reasoning is flawed. If you think abusing 
` trusted` is not safewashing, then your reasoning is flawed.

If you think safewashing will be temporary and not make it into released 
products, you will be wrong. This will happen even when you do not 
encourage it, but it is disappointing if you do. I am also disappointed 
you are choosing to defend this when called out. I think a good way to 
move forward would instead be to think about what additional tools are 
helpful to allow people to achieve their incremental safety goals 
without abusing ` trusted`. It's clear that the current design is not 
cutting it for people.

Why does this have to blow up in our face first? It is you who 
proclaimed "memory safety will kill C!"



 Jul 28



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


On 7/28/2024 6:49 AM, Timon Gehr wrote:

 Why does this have to blow up in our face first? It is you who proclaimed 
 "memory safety will kill C!"


I want D to be 100% memory safe as much or more than you do!

I am very concerned that making it difficult for programmers to transition
their 
code from unsafe to safe will mean - it doesn't happen.

Case in point - my struggles with getting the D front end  safe definitely 
influence my thinking about this.



 Jul 28



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


On 7/28/24 20:28, Walter Bright wrote:

 On 7/28/2024 6:49 AM, Timon Gehr wrote:

 Why does this have to blow up in our face first? It is you who 
 proclaimed "memory safety will kill C!"


 
 I want D to be 100% memory safe as much or more than you do!
 ...


This is why I am pushing back on this. You are doing something that 
seems to undermine one of your own priorities.


 I am very concerned that making it difficult for programmers to 
 transition their code from unsafe to safe will mean - it doesn't happen.
 
 Case in point - my struggles with getting the D front end  safe 
 definitely influence my thinking about this.


I am with you until this point, I just think the way to do it is to 
actually make interfaces memory safe. If you need more support from the 
compiler during the transition, put such features in there.

The dogfooding experience is an opportunity to improve the design of the 
toolbox. It's useful in general, e.g. maybe someone would like to enable 
certain safety checks in a ` trusted` function and only surgically 
disable the ones that are actually intended. This is what gave rise to 
the ` trusted` lambda antipattern, and there it would similarly be good 
to provide an alternative.



 Jul 29



prev sibling  parent reply Serg Gini <kornburn yandex.ru>  writes:


On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:


 Nvidia manager, curious about what programming language we are 
 using in DeepGlance as I claimed we care for memory safety.


I bet core tech (eye tracking and object detection) is C++ code :)



 Jul 25



 next sibling parent  Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:

 On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi 
 wrote:


 Nvidia manager, curious about what programming language we are 
 using in DeepGlance as I claimed we care for memory safety.


 I bet core tech (eye tracking and object detection) is C++ code 
 :)


You've lost :-P



 Jul 26



prev sibling  parent reply aberba <karabutaworld gmail.com>  writes:


On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:

 On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi 
 wrote:


 Nvidia manager, curious about what programming language we are 
 using in DeepGlance as I claimed we care for memory safety.


 I bet core tech (eye tracking and object detection) is C++ code 
 :)


I honestly don't get why D after 20yrs is being dragged (by a 
vocal minority) to become like rust. Shouldn't they be using rust 
already? A lot of very important new code is still being written 
in C++ (irrespective of its flaws). It's not like you can't write 
strict safe code in D either. Devs aren't stupid, it doesn't 
matter if strict is turned on by default or not at this point. 
They know what to do. There's way too many existing code in D to 
be dragging our feet with rust which is still niche by the way.



 Jul 26



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


On 7/26/24 10:57, aberba wrote:

 On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:

 On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:


 Nvidia manager, curious about what programming language we are using 
 in DeepGlance as I claimed we care for memory safety.


 I bet core tech (eye tracking and object detection) is C++ code :)


 
 I honestly don't get why D after 20yrs


` safe` existed before Rust was even a thing. It has just gained a bit 
in importance.


 is being dragged (by a vocal 
 minority) to become like rust. Shouldn't they be using rust already?


I am sure the people you are referring to, to the point they even exist, 
are already using Rust.


 A lot of very important new code is still being written in C++ 
 (irrespective of its flaws). It's not like you can't write strict safe 
 code in D either. Devs aren't stupid, it doesn't matter if strict is 
 turned on by default or not at this point. They know what to do.


No, in practice they build vulnerable systems. Devs do not know what 
they are doing, otherwise they would not be doing it like that.



 Jul 26



prev sibling  parent reply Don Allen <donaldcallen gmail.com>  writes:


On Friday, 26 July 2024 at 08:57:42 UTC, aberba wrote:

 On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:

 On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi 
 wrote:


 Nvidia manager, curious about what programming language we 
 are using in DeepGlance as I claimed we care for memory 
 safety.


 I bet core tech (eye tracking and object detection) is C++ 
 code :)


 I honestly don't get why D after 20yrs is being dragged (by a 
 vocal minority) to become like rust. Shouldn't they be using 
 rust already? A lot of very important new code is still being 
 written in C++ (irrespective of its flaws). It's not like you 
 can't write strict safe code in D either. Devs aren't stupid, 
 it doesn't matter if strict is turned on by default or not at 
 this point. They know what to do. There's way too many existing 
 code in D to be dragging our feet with rust which is still 
 niche by the way.


I could not agree more. Trying to glue Rust-like features onto 
this language really feels like ill-considered imitation, not a 
good look for a language that has already been accused of jumping 
on bandwagons. It also does not make technical sense to me. I've 
written comparable amounts of Rust and D and for ordinary 
applications without real-time constraints, I much prefer D, so I 
don't have to become an involuntary part of Rust's complex 
approach to memory management. Saying equivalent things in D is 
so much easier easier than in Rust. But the more baroque D 
becomes, the harder it will be for newcomers to find the subset 
of the language that works for them.



 Jul 26



 next sibling parent  Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Friday, 26 July 2024 at 22:26:03 UTC, Don Allen wrote:

 On Friday, 26 July 2024 at 08:57:42 UTC, aberba wrote:

 [...]


 I could not agree more. Trying to glue Rust-like features onto 
 this language really feels like ill-considered imitation, not a 
 good look for a language that has already been accused of 
 jumping on bandwagons. It also does not make technical sense to 
 me. I've written comparable amounts of Rust and D and for 
 ordinary applications without real-time constraints, I much 
 prefer D, so I don't have to become an involuntary part of 
 Rust's complex approach to memory management. Saying equivalent 
 things in D is so much easier easier than in Rust. But the more 
 baroque D becomes, the harder it will be for newcomers to find 
 the subset of the language that works for them.


I'm just asking not to derail what is _already_ in the language, 
and to stick with the current documentation:  trusted interface 
MUST be safe, otherwise all the narrative about D, and core 
developments caring about memory safety is just impossible to 
bake.



 Jul 27



prev sibling next sibling parent  Nick Treleaven <nick geany.org>  writes:


On Friday, 26 July 2024 at 22:26:03 UTC, Don Allen wrote:

 I could not agree more. Trying to glue Rust-like features onto 
 this language really feels like ill-considered imitation,


D's  safe is much more permissive than Rust.



 Jul 27



prev sibling  parent reply Paulo Pinto <pjmlp progtools.org>  writes:


On Friday, 26 July 2024 at 22:26:03 UTC, Don Allen wrote:

 On Friday, 26 July 2024 at 08:57:42 UTC, aberba wrote:

 On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:

 On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi 
 wrote:


 Nvidia manager, curious about what programming language we 
 are using in DeepGlance as I claimed we care for memory 
 safety.


 I bet core tech (eye tracking and object detection) is C++ 
 code :)


 I honestly don't get why D after 20yrs is being dragged (by a 
 vocal minority) to become like rust. Shouldn't they be using 
 rust already? A lot of very important new code is still being 
 written in C++ (irrespective of its flaws). It's not like you 
 can't write strict safe code in D either. Devs aren't stupid, 
 it doesn't matter if strict is turned on by default or not at 
 this point. They know what to do. There's way too many 
 existing code in D to be dragging our feet with rust which is 
 still niche by the way.


 I could not agree more. Trying to glue Rust-like features onto 
 this language really feels like ill-considered imitation, not a 
 good look for a language that has already been accused of 
 jumping on bandwagons. It also does not make technical sense to 
 me. I've written comparable amounts of Rust and D and for 
 ordinary applications without real-time constraints, I much 
 prefer D, so I don't have to become an involuntary part of 
 Rust's complex approach to memory management. Saying equivalent 
 things in D is so much easier easier than in Rust. But the more 
 baroque D becomes, the harder it will be for newcomers to find 
 the subset of the language that works for them.




already did that for me.

Similarly, Java with Panama and Graal native image, Swift, Go 
(even if I avoid it as much as possible), and Kotlin/Native keeps 
improving.

This is what I was looking forward back when I got "The D 
Programming Language" book, instead,   the ecosystems listed 
above either catched up in missing features where D had an edge, 
or sprung to the existence, creating much bigger ecosystems, 
while safety keeps being discussed on the forums, GC or not GC, 
and so on the eternal discussion.



 Jul 27



  parent reply aberba <karabutaworld gmail.com>  writes:


On Saturday, 27 July 2024 at 09:40:03 UTC, Paulo Pinto wrote:

 On Friday, 26 July 2024 at 22:26:03 UTC, Don Allen wrote:



 This is what I was looking forward back when I got "The D 
 Programming Language" book, instead,   the ecosystems listed 
 above either catched up in missing features where D had an 
 edge, or sprung to the existence, creating much bigger 
 ecosystems, while safety keeps being discussed on the forums, 
 GC or not GC, and so on the eternal discussion.


That's what happens when the vision is not clearly spelt out and 
iterated when such issues come up. It's leaves a void for other 
voices to fill in, making it seem like D is a risky bet for 
production.

I'm honestly not sure what the main vision or language direction 
for D is.



 Jul 27



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


On 7/27/24 19:35, aberba wrote:

 On Saturday, 27 July 2024 at 09:40:03 UTC, Paulo Pinto wrote:

 On Friday, 26 July 2024 at 22:26:03 UTC, Don Allen wrote:


 

 This is what I was looking forward back when I got "The D Programming 
 Language" book, instead,   the ecosystems listed above either catched 
 up in missing features where D had an edge, or sprung to the 
 existence, creating much bigger ecosystems, while safety keeps being 
 discussed on the forums, GC or not GC, and so on the eternal discussion.


 
 That's what happens when the vision is not clearly spelt out and 
 iterated when such issues come up. It's leaves a void for other voices 
 to fill in, making it seem like D is a risky bet for production.
 
 I'm honestly not sure what the main vision or language direction for D is.


It is a bit irritating to me how you ignore that a lot of those 
priorities, including ` safe`, have been clearly spelled out by 
Walter/Atila/Mike. On the forums, on bugzilla, by the work they have 
been doing, in their dconf talks, the safe by default DIPs, the meeting 
summaries. Who are those "other voices" filling a supposed "void"? Maybe 
you have some catching up to do?



 Jul 28



  parent reply aberba <karabutaworld gmail.com>  writes:


On Sunday, 28 July 2024 at 14:35:08 UTC, Timon Gehr wrote:

 On 7/27/24 19:35, aberba wrote:

 On Saturday, 27 July 2024 at 09:40:03 UTC, Paulo Pinto wrote:

 On Friday, 26 July 2024 at 22:26:03 UTC, Don Allen wrote:


 

 This is what I was looking forward back when I got "The D 
 Programming Language" book, instead,   the ecosystems listed 
 above either catched up in missing features where D had an 
 edge, or sprung to the existence, creating much bigger 
 ecosystems, while safety keeps being discussed on the forums, 
 GC or not GC, and so on the eternal discussion.


 
 That's what happens when the vision is not clearly spelt out 
 and iterated when such issues come up. It's leaves a void for 
 other voices to fill in, making it seem like D is a risky bet 
 for production.
 
 I'm honestly not sure what the main vision or language 
 direction for D is.


 It is a bit irritating to me how you ignore that a lot of those 
 priorities, including ` safe`, have been clearly spelled out by 
 Walter/Atila/Mike. On the forums, on bugzilla, by the work they 
 have been doing, in their dconf talks, the safe by default 
 DIPs, the meeting summaries. Who are those "other voices" 
 filling a supposed "void"? Maybe you have some catching up to 
 do?


I don't disagree I do have some catching up to do. Also found 
this write-up from 2yrs ago 
(https://github.com/dlang/vision-document) and I've not been 
using D much since 3-4yrs ago besides some few hobby projects and 
popping up here recently.

I wish this document was referenced whenever such discussions 
come (assuming it's still relevant).


This back-and-forth about the action plan to move to  safe by 
default (if it's even going to happen) isn't encouraging... I 
don't mind the debates, but this doing seem to be yield a 
resolution. Maybe you guys should meetup and hash things out.

We the regular users are the ones supposed to be pushing back, 
not the top contributors (core members??).



 Jul 28



 next sibling parent  aberba <karabutaworld gmail.com>  writes:


On Monday, 29 July 2024 at 05:30:51 UTC, aberba wrote:

 On Sunday, 28 July 2024 at 14:35:08 UTC, Timon Gehr wrote:

 [...]


 I don't disagree I do have some catching up to do. Also found 
 this write-up from 2yrs ago 
 (https://github.com/dlang/vision-document) and I've not been 
 using D much since 3-4yrs ago besides some few hobby projects 
 and popping up here recently.

 I wish this document was referenced whenever such discussions 
 come (assuming it's still relevant).


 This back-and-forth about the action plan to move to  safe by 
 default (if it's even going to happen) isn't encouraging... I 
 don't mind the debates, but this doing seem to be yield a 
 resolution. Maybe you guys should meetup and hash things out.

 We the regular users are the ones supposed to be pushing back, 
 not the top contributors (core members??).


*I meant doesn't seem to be yielding any results/resolution to 
the direction to getting D to  safe by default considering that 
is/was the vision



 Jul 28



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


On 7/29/24 07:30, aberba wrote:

 
 This back-and-forth about the action plan to move to  safe by default 
 (if it's even going to happen) isn't encouraging... I don't mind the 
 debates,


Well, this debate is not about default safety at all, it is not even 
about safety checks, it is about properly understanding the difference 
between ` system` and ` trusted`.


 but this doing seem to be yield a resolution.


Designing a good programming language is hard.


 Maybe you guys should meetup and hash things out.
 ...


That happens too.


 We the regular users are the ones supposed to be pushing back, not the 
 top contributors (core members??).


This sentiment is wild to me. There is no such separation. This is an 
open source project, with a lot of transparency. I think these public 
debates are actually a strength of D. People say what they think.

If you check out my track record with D, I do have some particularly 
high-profile contributions to the compiler, but a majority of the work I 
have spent on D is actually forum debates and bugzilla issues.

There are also contributors who are mostly silent here but do a lot of 
very important work on the compilers. Walter is both a prolific 
contributor to the compiler and a prolific debater on the forums. I 
think he is right about a lot of things, but clearly most communication 
is required when there are disagreements.



 Jul 30



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


I understand where you're coming from with this. Your proposal has advantages. 
I'm not sure I can sell that, though.

Going from 3 safety attributes to 4 attributes is just going to confuse people. 
There's no simple, obvious rule saying what checks will be on, and which will
be 
off. Calling unsafe functions? accessing mutable globals? pointer casting? C 
strings? unions? All of these are difficulties I face with converting the 
compiler source code, and they don't have simple answers. Nobody is going to 
remember which checks are turned on by the 4th attribute and which are disabled.

Rust has only one -- unsafe -- but converting code to Rust is a massive 
undertaking, one that requires redesigning the algorithms and data structures. 
It's such an undertaking that when one manages to do it, it gets a Hackernews 
article. I'm impressed that Rust managed to sell that. I've been told 
anecdotally that Rust developers often just slap 'unsafe' everywhere and get 
their project working. Does that mean Rust is a safewashed fraud of a language?

 trusted turns off safety checks. That's all it does. How it is used is up to 
the programmer, and always will be.



 Jul 25



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


On 26/07/2024 6:14 AM, Walter Bright wrote:

 I understand where you're coming from with this. Your proposal has 
 advantages. I'm not sure I can sell that, though.


Chuck it into core.attributes, sold.

The only people who care about it, know about it.

Everyone else? Doesn't have to know about it.

As it is regular ol' `` system``.



 Jul 25



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


On 7/25/24 20:14, Walter Bright wrote:

 I've been told anecdotally that Rust developers often just slap 'unsafe' 
 everywhere and get their project working. Does that mean Rust is a 
 safewashed fraud of a language?
 ...


To the extent that this is happening, it is. Absolutely yes if the core 
team starts promoting this practice.


  trusted turns off safety checks. That's all it does.


You are thinking operationally about a feature that is defined semantically.


 How it is used is up to the programmer, and always will be.


Yes, so please start leading by example.



 Jul 25



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


On 7/25/24 20:14, Walter Bright wrote:

 
 
 Going from 3 safety attributes to 4 attributes is just going to confuse 
 people. There's no simple, obvious rule saying what checks will be on, 
 and which will be off. Calling unsafe functions? accessing mutable 
 globals? pointer casting? C strings? unions? All of these are 
 difficulties I face with converting the compiler source code, and they 
 don't have simple answers. Nobody is going to remember which checks are 
 turned on by the 4th attribute and which are disabled.


Well, perhaps you should read my proposal again then.



 Jul 25



prev sibling  parent  Martin <nitramlxl googlemail.com>  writes:


On Thursday, 25 July 2024 at 02:32:29 UTC, Walter Bright wrote:

 [...] goals with D was to make it easier for managers [...]


I laughed so hard, i spilled my coffee all over me



 Jul 25



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


On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:

 On Monday, 8 July 2024 at 10:30:56 UTC, Nick Treleaven wrote:

 On Monday, 8 July 2024 at 08:48:56 UTC, Martyn wrote:

 * goes memory-safe by default, will break existing code.


 The idea is that the next 
 [edition](https://forum.dlang.org/post/tskwospngntbnqiuxbag forum.dlang.org)
is  safe by default. Existing code will not be broken.


 We have very few details on what this will look like for 
 someone that doesn't want it.


` system:`


 Not breaking existing code is far from sufficient for those 
 writing unsafe code. Inference is useless because there's 
 nothing to infer,


 system would be inferred for functions that use unsafe features.


  trusted loses its meaning,


 trusted continues to mean safe interface, unsafe implementation.


 there's needless boilerplate all over the place, and


` system:`


 it's more complex for new users of the language. There's no


Users get an error instead of accidentally corrupting memory. 
That's a massive win for new users, assuming they use newer 
editions.


 evidence that any of this has been given consideration, and all 
 apparently because adding -safe to the compilation command is 
 too much of a burden for those wanting the additional checks.


That wouldn't be reliable and wouldn't allow safe/unsafe code to 
interact. We need the code to state what its default is.



 Jul 09



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


On 7/9/24 17:53, Nick Treleaven wrote:

 ...
 ` system:`
 ...


Has similar issues as ` safe:`.



 Jul 13



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


On Tuesday, 9 July 2024 at 15:53:04 UTC, Nick Treleaven wrote:

 That wouldn't be reliable and wouldn't allow safe/unsafe code 
 to interact. We need the code to state what its default is.


A good first step is if a module could state its default. IMO, 
this makes the most sense. The next edition should have ` safe` 
by default and experts(!) can undo that changing their 
new-edition modules’ default back to ` system` when it makes 
sense. Writing system code is an expert activity. D shouldn’t bar 
experts from their tools, just not expose anyone to them asking 
for them.

The default should, essentially, be maximal safety. This doesn’t 
mean you can’t disable those checks, but you have to specifically 
ask for it.

It means `scope` plus extra things. `scope` makes strong 
guarantees and thus is very useful for avoiding unnecessary 
allocations. In ` safe` code, incorrect use will be diagnosed. In 
` system` code, `scope` is not checked, but nonetheless makes all 
the guarantees. `in` (with the preview) is even worse because it 
means `scope`, but also looks innocuous. You need expert 
knowledge to get it right. `scope` stands out a little more, 
fortunately, but `in`? “Oh, this is an input parameter, of course 
let’s mark it with `in` to enable some optimizations, that’s what 
it’s for.” Right, or easily corrupt memory if you don’t also use 
` safe`.

```d
// compile with -preview=in -preview=dip1000

import std.stdio;

const(int)[] global;

void f(in int[] xs) { global = xs; }

void g() { f([1,2,3]); }

void main()
{
     g();
     writeln(global); // (random garbage)
}
```

Maybe this is just a fluke but to me it feels ` system` code is 
getting more dangerous and more expert-only over time.



 Jul 22



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


On Saturday, 6 July 2024 at 23:39:54 UTC, Sebastian Nibisz wrote:

 On Saturday, 6 July 2024 at 23:10:02 UTC, Walter Bright wrote:

 On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:

 Seriously? Any language is safe in this case, you just need 
 to write safe code.


 Enabling the checks is quite different from writing code with 
 no bugs in it.


 But you have to remember to enable it. Inexperienced programmer 
 usually won't do this and will build unsafe code unconsciously.


This is the single best reason to enable ` safe` by default. 
Writing correct ` system` code is as hard as writing ` trusted` 
code, and both require the programmer to know the language very, 
very well. You shouldn’t mark a function ` system` or ` trusted` 
unless you understand exactly why that’s the right thing.

---

The only big issue with ` safe` by default is higher-order 
functions. Because ` safe` makes no guarantees (unlike `pure` or 
`nothrow`), requiring a callback delegate to be ` safe` makes no 
sense generally. (In contrast, requiring a `pure` or `nothrow` 
callback can make sense in special circumstances. Practically, if 
your higher-order function can be called with a ` safe` callback, 
it can be called with a ` system` callback. The problem is that 
the language does not understand this.

This means, in general, higher-order functions must be overloaded:
```d
void hof(void delegate()  system callback)  system => 
hof(cast(void delegate()  safe)callback);

void hof(void delegate()  safe callback)  safe
{
     callback();
}
```

For application code, it might be fine if a callback is 
needlessly required to be ` safe` if the application is ` safe` 
code anyway. Libraries can’t make such assumptions on usage, 
though.

Top-level ` safe:` does not influence callback types. In [a DIP 
Idea](https://forum.dlang.org/thread/rtccewhszjtldwowuhsx forum.dlang.org), I
proposed `default  safe module` declarations, so that for any declaration
lexically in the module, ` safe` is applied by default instead of ` system`.



 Jul 19



  parent reply Lance Bachmeier <no spam.net>  writes:


On Friday, 19 July 2024 at 14:57:17 UTC, Quirin Schroll wrote:


 This is the single best reason to enable ` safe` by default.


It's also a good example of the pointless debates that go on 
around here. I know language design is hard. This is not, 
however. Leave D as unsafe by default and add a switch to enable 
it, or make it safe by default and add a switch to disable it. It 
doesn't matter.

It's been debated for years and the solution is trivial. In the 
meantime, the rest of the programming world has been advancing. 
This should have been a ten minute decision.



 Jul 19



  parent reply "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Fri, Jul 19, 2024 at 04:03:42PM +0000, Lance Bachmeier via Digitalmars-d
wrote:

 On Friday, 19 July 2024 at 14:57:17 UTC, Quirin Schroll wrote:
 

 This is the single best reason to enable ` safe` by default.


 
 It's also a good example of the pointless debates that go on around
 here. I know language design is hard. This is not, however. Leave D as
 unsafe by default and add a switch to enable it, or make it safe by
 default and add a switch to disable it. It doesn't matter.
 
 It's been debated for years and the solution is trivial. In the
 meantime, the rest of the programming world has been advancing. This
 should have been a ten minute decision.


This is typical of the D development process.  Easy decisions are hard,
and hard decisions are impossible.  This is why after more than a decade
we still don't have a good story for `shared`, while a 10-minute
decision like  safe by default has been held up for years simply because
of a trivial disagreement (Walter wants  safe to apply to everything,
include extern(C), everyone else disagrees on the extern(C) part). In
all likelihood it will be another decade before we get  safe by default.

I'm rather tempted to throw my weight behind Adam's fork at this
point...


T

-- 
I am Ohm of Borg. Resistance is voltage over current.



 Jul 19



  parent  Nick Treleaven <nick geany.org>  writes:


On Friday, 19 July 2024 at 16:17:49 UTC, H. S. Teoh wrote:

 while a 10-minute decision like  safe by default has been held 
 up for years simply because of a trivial disagreement (Walter 
 wants  safe to apply to everything, include extern(C), everyone 
 else disagrees on the extern(C) part).


That wasn't really the main problem. The main problem was 
breaking existing code. If we proceed with editions, that problem 
can be solved.



 Jul 19



prev sibling  parent  Kagamin <spam here.lot>  writes:


On Friday, 5 July 2024 at 19:42:30 UTC, Steven Schveighoffer 
wrote:

 Compare this to Rust which is safe unless you ask for unsafe 
 blocks.


And since rust is too strict about safety you either have to use 
unsafe blocks or abandon rust, cf 
https://loglog.games/blog/leaving-rust-gamedev/



 Jul 23



prev sibling  parent  matheus <matheus gmail.com>  writes:


Just sharing this blog post about safe by default strategy on 
OpenD:

http://dpldocs.info/this-week-in-arsd/Blog.Posted_2024_03_25.html

Matheus.



 Jul 28