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.

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.

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.

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.

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?

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

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

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 finally happening in Swift, C#, Java, Nim, Go, while D keeps 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.

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

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.