From: cross@spitfire.i.gajendra.net
In article <10ffsku$1233b$2@dont-email.me>,
Simon Clubley wrote:
>On 2025-11-15, Dan Cross wrote:
>> In article <10f4oi1$25lkk$2@dont-email.me>,
>> Simon Clubley wrote:
>>>
>>>The unsafe keyword is a hack implemented in languages that have not been
>>>designed correctly.
>>
>> Wait, Simon, tell me how you really feel.
>>
>
>Well, Simon is known to have opinions. :-)
:-D
>>>The Ada approach, of disabling checks on a specific
>>>reference to a variable instead of disabling checks within a whole block
>>>of code, is far superior.
>>
>> It's unclear to me how this is materially different.
>>
>> In Rust, blocks return the value of the last expression they
>> contain, so an `unsafe` block may refer to a single expression.
>> However, I disagree with the above in the sense that the ability
>> to introduce scope when doing something `unsafe` can be
>> incredibly useful. But what if the expression is really a
>> statement?
>>
>> For example:
>>
>> ```rust
>> unsafe {
>> use core::intrinsics::volatile_copy_memory;
>> let src = entry.virt_page_addr() as *const arch::Page;
>> volatile_copy_memory(page, src, 1);
>> }
>> ```
>
>And that is exactly the kind of thing I am talking about. :-)
>
>Of those three statements, only the last one appears to be the unsafe one.
This is true, but also the sort of thing where I want to
localize the scope of both the use statement, as well as `src`.
>It is also the kind of thing I was reacting to when I saw Arne's
>example and went YUCK!, YUCK!, YUCK! :-)
Heh.
>> There's no need to leak the existence of `src` or that one is
>> using the volatile memcpy intrinsic here. I suppose could could
>> also write this as,
>
>If that is important, I would have placed the whole sequence inside a
>local block as you do below.
>
>> ```rust
>> {
>> use core::intrinsics::volatile_copy_memory;
>> let src = entry.virt_page_addr() as *const arch::Page;
>> unsafe {
>> volatile_copy_memory(page, src, 1);
>> }
>> }
>> ```
>
>And this example is much closer to the Ada way. Related statements still
>get checked and only one specific statement, the actual statement that is
>unsafe, has checks disabled.
Let me be clear: _all_ of those expressions get checked. The
`unsafe` superset just lets you do a few additional things; the
contract is that you, the programmer, have some external domain
knowledge that the compiler cannot derive from the code, and you
are asserting that you have verified that the language's
requirements vis its semantics hold, since the compiler cannot
check that for you. `unsafe` does not mean you get to violate
the language's rules; it just means that you're taking
responsibility for them when the compiler would ordinarily do
that for you.
>> etc.
>>
>>
>>>For example, this is how you do an unsafe conversion in Ada:
>>>
>>>https://adaic.org/resources/add_content/docs/95style/html/sec_5/5-9-1.html
>>
>> This example seems equivalent to an `unsafe fn` in Rust. An
>> unsafe conversion of this nature might use `std::mem::transmute`
>> in that world.
>
>The Ada example localises the unsafe bit down to a specific operation
>within a statement, not a full statement, and certainly not a full function.
Ah, I'm being unclear, then. In Rust, `unsafe fn` means that
the function must be _called_ from an `unsafe` block. It does
not mean that the statements inside the function are implicitly
wrapped in an `unsafe` block (though in fairness it used to;
this was changed in, I believe, the 2024 edition of the
language).
Anyway, I think it's unfair to say that `unsafe` blocks are a
misfeature, or a sign of poor design. In expression-oriented
languages, they're sort of size-to-fit.
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
