Stream: t-lang

Topic: unsafe blocks in unsafe fn

pnkfelix (Jan 23 2020 at 21:45, on Zulip):

hey @Josh Triplett , regarding your recent comment: does that mean you would be in favor of #[unsafe] fn foo if it were written #[unsafe_to_call] fn foo or something similar?

pnkfelix (Jan 23 2020 at 21:46, on Zulip):

(I decided not to keep pushing #[unsafe] in the meeting because it seemed like few people were interested in pursuing that avenue of discussion, but I don't think you chimed in at that time.)

pnkfelix (Jan 23 2020 at 21:47, on Zulip):

the idea was originally proposed by ogoffart here on the RFC thread

pnkfelix (Jan 23 2020 at 21:48, on Zulip):

(though I don't know if I agree with their generalization to #[unsafe] trait UnsafeTrait { } ; that seems premature to me, especially since I think unsafe trait has no implied effect on its methods and default bodies.)

pnkfelix (Jan 23 2020 at 21:57, on Zulip):

(that is, I don't see what the use of the attribute form buys one in terms of expressiveness there; at least with the #[unsafe] fn I can see how it differs from unsafe fn)

Josh Triplett (Jan 23 2020 at 21:59, on Zulip):

I would be slightly in favor, albeit that's a very verbose syntax.

pnkfelix (Jan 23 2020 at 21:59, on Zulip):

#[unsafe_to_call] fn is verbose? or #[unsafe] fn?

Josh Triplett (Jan 23 2020 at 21:59, on Zulip):

The former.

pnkfelix (Jan 23 2020 at 22:00, on Zulip):

okay.But I assume the latter fails to convey intent sufficiently, right ?

Josh Triplett (Jan 23 2020 at 22:00, on Zulip):

Yeah, confusing similarity.

Josh Triplett (Jan 23 2020 at 22:00, on Zulip):

I don't have a good syntax to suggest.

pnkfelix (Jan 23 2020 at 22:00, on Zulip):

another option that @RalfJ had put forward was something like #[safe_body] unsafe fn foo(..) { ... }

Josh Triplett (Jan 23 2020 at 22:01, on Zulip):

I prefer the lint approach. But I like the concept of #[unsafe_to_call], just not the spelling.

pnkfelix (Jan 23 2020 at 22:01, on Zulip):

which is again verbose, but perhaps captures intent nicely (especially since the fact that the body is safe is an implementation detail, and thus need not be part of the header.

pnkfelix (Jan 23 2020 at 22:02, on Zulip):

I.e. maybe we could get away with adding #[safe], and do unsafe fn foo(...) { #![safe] ... }

pnkfelix (Jan 23 2020 at 22:02, on Zulip):

which sidesteps the whole failure to reserve safe as a keyword.

pnkfelix (Jan 23 2020 at 22:03, on Zulip):

and of course its quite likely that all of this was already debated on the RFC

Lokathor (Jan 23 2020 at 22:04, on Zulip):

could some sort of synonym help here?

pnkfelix (Jan 23 2020 at 22:05, on Zulip):

I suppose #![safe] ends up turning into the lint approach

pnkfelix (Jan 23 2020 at 22:06, on Zulip):

i.e. unsafe fn foo(...) { #![safe] ... } seems like it would be equivalent to unsafe fn foo(...) { #![deny(unsafe_acts_outside_unsafe_block)] ...}, or whatever we name the lint.

Lokathor (Jan 23 2020 at 22:07, on Zulip):

something like danger fn set_len(&self, new_len)

pnkfelix (Jan 23 2020 at 22:09, on Zulip):

i'll admit I don't see why we need a new keyword for this concept. An attribute (i.e. #[danger] fn set_len(&mut self, new_len) seems fine to me.)

pnkfelix (Jan 23 2020 at 22:10, on Zulip):

(as long as adding the attribute cannot make us start accepting code with UB that would have otherwise been rejected, that is )

Lokathor (Jan 23 2020 at 22:11, on Zulip):

attributes are often quite clunky, but since it's infrequent that this one would be used it's probably fine

centril (Jan 23 2020 at 22:12, on Zulip):

I think adding attributes (particularly #[unsafe] due to its keyword nature) or wholly new mechanisms rather than small edition based tweaks uses up relatively a lot of spec/compiler complexity for relatively little gain as #[unsafe/safe/unsafe_to_call] is unlikely to get widespread use

centril (Jan 23 2020 at 22:13, on Zulip):

If we don't make edition changes as proposed in the RFC, I would prefer to tweak the linting, and leave it there

Lokathor (Jan 23 2020 at 22:28, on Zulip):

Specifically an attribute
1) displays poorly in generated rustdoc (relatively fixable)
2) doesn't have a defined order when there is more than one on the same function (harder to fix but maybe rustfmt could help)

example: set_len is probably inline, and you could imagine must_use being added to other unsafe to call functions that are inline, such as index_unchecked or similar.

Many disorganized attributes is fine if they are largely unimportant to the usage, such as inline being optimization only, and must_use being a hint only. When the attribute means that you need an unsafe block and you need to be manually verifying things, it is not so fun.

Lokathor (Jan 23 2020 at 22:29, on Zulip):

put another way: safe / unsafe_to_call_but_safe_body / unsafe_body is as important as async, and async is not an attribute either.

centril (Jan 23 2020 at 22:32, on Zulip):

if not more important due to the well.. unsafety

Lokathor (Jan 25 2020 at 02:58, on Zulip):

@Josh Triplett if you saw it in the RFC thread, how did you feel about the suggestion of allowing unsafe to prefix a single expression without need of braces:

unsafe v.set_len(0);
let x_val = unsafe *x;
// and so on
Josh Triplett (Jan 25 2020 at 02:59, on Zulip):

Did see it, really not a fan. Unsafe should stand out.

Lokathor (Jan 25 2020 at 03:00, on Zulip):

that makes it harder to program much of the time :/

Lokathor (Jan 25 2020 at 03:01, on Zulip):

i think it especially hinders calls where the return value is immediately checked with if or match

Lokathor (Jan 25 2020 at 03:02, on Zulip):

which is like, 97% of all the unsafe calls i make

nikomatsakis (Feb 03 2020 at 16:35, on Zulip):

we opted against this "braceless unsafe" in the past on the basis of the non-obviousness of its scope (this, btw, is a good example of the kind of "jurispredunce" I think we should be accumulating in a sort of FAQ)

Last update: Jun 07 2020 at 10:40UTC