November 15, 2022

On Tuesday, 15 November 2022 at 06:44:16 UTC, Ali Çehreli wrote:

>

In summary, you are right but the compiler cannot do anything about it in all cases and we wouldn't want it to spend infinite amount of time to try to determine everything.

Well, there's another way to look at it: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html ('Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler tries to determine whether or not code upholds the guarantees, it’s better for it to reject some valid programs than to accept some invalid programs. Although the code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.”')

Are you saying that the D safety model is different? In the sense that if the D compiler doesn’t have enough information to be confident, it will accept the code?

November 15, 2022

On Tuesday, 15 November 2022 at 13:01:39 UTC, Siarhei Siamashka wrote:

>

Well, there's another way to look at it: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html ('Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler tries to determine whether or not code upholds the guarantees, it’s better for it to reject some valid programs than to accept some invalid programs. Although the code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.”')

Are you saying that the D safety model is different? In the sense that if the D compiler doesn’t have enough information to be confident, it will accept the code?

D's safety model is the same. In @safe code, D will reject anything that the compiler cannot say for sure is memory safe. However, unlike in Rust, @safe is not the default in D, so you must mark your code as @safe manually if you want to benefit from these checks.

November 15, 2022

On Tuesday, 15 November 2022 at 13:16:18 UTC, Paul Backus wrote:

>

D's safety model is the same. In @safe code, D will reject anything that the compiler cannot say for sure is memory safe. However, unlike in Rust, @safe is not the default in D, so you must mark your code as @safe manually if you want to benefit from these checks.

I specifically asked for Ali's opinion. Because the context is that the compiler couldn't catch a memory safety bug in the code that was annotated as @safe (but without -dip1000) and Ali commented that "the compiler cannot do anything about it in all cases and we wouldn't want it to spend infinite amount of time to try to determine everything". This sounds like he justifies the compiler's failure and accepts this as something normal.

The https://dlang.org/spec/memory-safe-d.html page also provides a rather vague statement: "@safe functions have a number of restrictions on what they may do and are intended to disallow operations that may cause memory corruption". Which kinda means that it makes some effort to catch some memory safety bugs. This weasel language isn't very reassuring, compared to a very clear Rust documentation.

November 15, 2022
On 11/15/22 06:05, Siarhei Siamashka wrote:

> Ali commented that "the
> compiler cannot do anything about it in all cases and we wouldn't want
> it to spend infinite amount of time to try to determine everything".

Yes, that's my understanding.

> This sounds like he justifies the compiler's failure and accepts this as
> something normal.

Despite my lack of computer science education, I think the compiler's failure in analyzing source code to determine all bugs is "normal". I base my understanding on the "halting problem" and the "separate compilation" feature that D supports.

> The https://dlang.org/spec/memory-safe-d.html page also provides a
> rather vague statement: "@safe functions have a number of restrictions
> on what they may do and are intended to disallow operations that may
> cause memory corruption". Which kinda means that it makes some effort to
> catch some memory safety bugs.

Exactly. My understanding is that @safe attempts to remove memory corruptions. @live is being worked on to improve the situation by tracking liveness of data.

> This weasel language isn't very
> reassuring, compared to a very clear Rust documentation.

That's spot on.

Ali

November 16, 2022

On Tuesday, 15 November 2022 at 14:05:42 UTC, Siarhei Siamashka wrote:

>

On Tuesday, 15 November 2022 at 13:16:18 UTC, Paul Backus wrote:

>

D's safety model is the same. In @safe code, D will reject anything that the compiler cannot say for sure is memory safe. However, unlike in Rust, @safe is not the default in D, so you must mark your code as @safe manually if you want to benefit from these checks.

I specifically asked for Ali's opinion. Because the context is that the compiler couldn't catch a memory safety bug in the code that was annotated as @safe (but without -dip1000) and Ali commented that "the compiler cannot do anything about it in all cases and we wouldn't want it to spend infinite amount of time to try to determine everything". This sounds like he justifies the compiler's failure and accepts this as something normal.

The https://dlang.org/spec/memory-safe-d.html page also provides a rather vague statement: "@safe functions have a number of restrictions on what they may do and are intended to disallow operations that may cause memory corruption". Which kinda means that it makes some effort to catch some memory safety bugs. This weasel language isn't very reassuring, compared to a very clear Rust documentation.

The goal of @safe is to ensure that memory corruption cannot possibly occur in @safe code, period--only in @system or @trusted code. If the documentation isn't clear about this, that's failure of the documentation.

However, there are some known issues with @safe that require breaking changes to fix, and to make migration easier for existing code, those changes have been hidden behind the -dip1000 flag. So in practice, if you are using @safe without -dip1000, you may run into compiler bugs that compromise memory safety.

That's what happened in your example. Slicing a stack-allocated static array shouldn't be allowed in @safe code without -dip1000, but the compiler allows it anyway, due to a bug, and the fix for that bug is enabled by the -dip1000 switch.

1 2
Next ›   Last »