Hacker News Reader

Comment by likeabbas | Hacker News Reader

I think `unsafe` would have been more aptly named `compiler_unverifiable`. IMO there would be less apprehension to using `unsafe` when it's needed.

View on HN

As someone who mainly uses higher level languages, doesn't care for C/C++ and really likes Rust, I'm glad it was named so strongly and that safety and correctness is very important in the community.

It creates a strong incentive to only write safe Rust, which is great for the vast majority of people.

I think the incentive to write compiler verifiable Rust would be the same as safe Rust, but with less fear for the situations where you do need to bypass the borrow checker such as with cyclical references in graphs (currently doing this right now by re-writing a basic NN in Rust). Even the standard library uses unsafe for certain situations.

> with less fear for the situations where you do need to bypass the borrow checker such as with cyclical references in graphs

That's a pretty tricky thing to get right, and with the consequence for getting it wrong being UB, at least a little fear is warranted.

`compiler_unverifiable` isn't risky enough for you?

It doesn't have the same connotations as `unsafe`.

But it’s the true definition being stated. Unsafe is subjective, compiler unverifiable isn’t

So?

This is like applications adding artificial delay to operations so users aren't surprised they complete so quickly.

User understanding is more important than definitional correctness.

I don’t understand why you want people to be afraid of code though. It’s just code. We don’t need a scary connotation to make people think they should shoot for completely compiler verifiable rust in every line they can write.

Users who don't even know the meaning of "unsafe" almost definitely shouldn't be writing unsafe code.

That's an elitist mindset

It's a user-friendly mindset.

User-friendly is subjective. I think it would be more user friendly to tell users "hey, this code you're writing can't be verified by the compiler" rather than "hey, this code is unsafe. beware"

What it boils down to is "Users who don't even know what a trigger is should be discouraged from handling footguns". Sure, if you don't have the resources to learn about the subject, you might miss out on some fun, but it's much more likely that you'd blow off your foot instead, which would be much less fun.

In this case it would be nice if operations that are type-safe and don't read or write memory at all, such as mm256_shuffle_epi8, were available in safe rust.

It's a work in progress, on nightly there is a safe and portable SIMD abstraction under development in std::simd.

e.g. "mm256_shuffle_epi8" on X64+AVX2, ARM64+NEON and plain ARM: https://rust.godbolt.org/z/7rjKE93Kn

It currently only works with constant shuffle masks but dynamic shuffles are on the to-do list.

This is helpful for the use cases that want to rearrange bytes in a fixed pattern, but it cannot yet express a stream vbyte decoder (out = pshufb(in, shuffle_patterns[len_mask])) or a check for which bytes are in small set of bytes with distinct lower nibbles and the high bit not set (eq(in, pshufb(set, in))) yet.

If it's to be portable it needs an extra instruction on one platform or the other because tbl and vpshufb do different things :(

`unchecked` might be more palatable, but I agree that there is some uncomfortable mismatch between the meanings of "unsafe" and `unsafe`.

Reply on news.ycombinator.com