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.

In that regard, C# with the low level improvements introduced and improved upon since C# 7 (currently C# 12), alongside Native AOT, 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.

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.

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.

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!"

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.

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?

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.

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.

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.

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.