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.

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.

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.

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.