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

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.

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.

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.

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.

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.

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.

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`.)

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.)