How can Rust be safe if programmers can just slap on the "unsafe" attribute?

I understand where you're coming from with this. Your proposal has advantages. I'm not sure I can sell that, though.

Going from 3 safety attributes to 4 attributes is just going to confuse people. There's no simple, obvious rule saying what checks will be on, and which will be off. Calling unsafe functions? accessing mutable globals? pointer casting? C strings? unions? All of these are difficulties I face with converting the compiler source code, and they don't have simple answers. Nobody is going to remember which checks are turned on by the 4th attribute and which are disabled.

Rust has only one -- unsafe -- but converting code to Rust is a massive undertaking, one that requires redesigning the algorithms and data structures. It's such an undertaking that when one manages to do it, it gets a Hackernews article. I'm impressed that Rust managed to sell that. I've been told anecdotally that Rust developers often just slap 'unsafe' everywhere and get their project working. Does that mean Rust is a safewashed fraud of a language?

@trusted turns off safety checks. That's all it does. How it is used is up to the programmer, and always will be.

On 26/07/2024 6:14 AM, Walter Bright wrote:
> I understand where you're coming from with this. Your proposal has advantages. I'm not sure I can sell that, though.

Chuck it into core.attributes, sold.

The only people who care about it, know about it.

Everyone else? Doesn't have to know about it.

As it is regular ol' ``@system``.

On Thursday, 25 July 2024 at 02:32:29 UTC, Walter Bright wrote:
> [...] goals with D was to make it easier for managers [...]

I laughed so hard, i spilled my coffee all over me

On 7/25/24 19:09, Walter Bright wrote:
> How can Rust be safe

Rust is indeed a memory-unsafe language. Yet better memory safety is one of its key features.

Rust had its share of controversy over popular libraries with memory safety bugs. However, those were unintentional.

Also:

https://github.com/rust-lang/rust/labels/I-unsound
https://github.com/rust-lang/rust/issues/25860 (open since 2015)
https://github.com/Speykious/cve-rs

> if programmers can just slap on the "unsafe" attribute?
> 

(The "unsafe" attribute is not a memory safety problem. Lack of the "unsafe" attribute on a function with a memory-unsafe interface is.)

It's a question of the community culture. Do Rust programmers _actually_ put "unsafe" blocks everywhere, carelessly? This is exactly what this is about.

I am taking issue with throwing overboard even the aspiration of memory safety. You won't get D widely recognized as a safer language if its ecosystem is actively encouraged to build on careless `@trusted` slapping-on, even on functions where it is completely obvious that they have an unsafe interface.

On 7/25/24 20:14, Walter Bright wrote:
> I've been told anecdotally that Rust developers often just slap 'unsafe' everywhere and get their project working. Does that mean Rust is a safewashed fraud of a language?
> ...

To the extent that this is happening, it is. Absolutely yes if the core team starts promoting this practice.

> @trusted turns off safety checks. That's all it does.

You are thinking operationally about a feature that is defined semantically.

> How it is used is up to the programmer, and always will be.

Yes, so please start leading by example.

On 7/25/24 20:14, Walter Bright wrote:
> 
> 
> Going from 3 safety attributes to 4 attributes is just going to confuse people. There's no simple, obvious rule saying what checks will be on, and which will be off. Calling unsafe functions? accessing mutable globals? pointer casting? C strings? unions? All of these are difficulties I face with converting the compiler source code, and they don't have simple answers. Nobody is going to remember which checks are turned on by the 4th attribute and which are disabled.

Well, perhaps you should read my proposal again then.

On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:

> Nvidia manager, curious about what programming language we are using in DeepGlance as I claimed we care for memory safety.

I bet core tech (eye tracking and object detection) is C++ code :)

On Thursday, 25 July 2024 at 20:18:27 UTC, Serg Gini wrote:
> On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:
>
>> Nvidia manager, curious about what programming language we are using in DeepGlance as I claimed we care for memory safety.
>
> I bet core tech (eye tracking and object detection) is C++ code :)

You've lost :-P