Stream: general

Topic: Change behavior of `unsafe` fns in new edition?


Lukas Kalbertodt (Jan 12 2020 at 11:04, on Zulip):

Many people are not happy with the fact that unsafe fns can do unsafe things inside the function body. Many would prefer if explicit unsafe blocks were required, like in normal functions. But let's not talk about if we want that. My question is: can this behavior be changed in a new edition?
Seems like a surface level change to me. It does not change APIs in any way and is crate local. Should be possible, right?

kennytm (Jan 12 2020 at 12:53, on Zulip):

https://github.com/rust-lang/rfcs/pull/2585

Lukas Kalbertodt (Jan 12 2020 at 13:30, on Zulip):

Thanks! That's great

gnzlbg (Jan 12 2020 at 19:51, on Zulip):

@Lukas Kalbertodt yes, it can be changed in a new edition

RalfJ (Jan 14 2020 at 21:58, on Zulip):

@Lukas Kalbertodt I'd be happy for any support in reviving that RFC and pushing it over the finish line -- assuming we can get the conesus for that :)

Lukas Kalbertodt (Jan 14 2020 at 22:05, on Zulip):

@RalfJ That would be great. I will take a look soon, but I'm currently having lots of other stuff in my queue. Trying to get used to T-libs life :P

Lokathor (Jan 14 2020 at 22:54, on Zulip):

I still think that it would be a very bad idea, very detrimental to unsafe code authors.

centril (Jan 15 2020 at 07:58, on Zulip):

I would be fine with accepting the RFC if we also allow fn foo() -> R = expr;

oli (Jan 15 2020 at 08:13, on Zulip):

:upside_down: fn foo: fn() -> R = expr; for symmetry with other globals

oli (Jan 15 2020 at 08:14, on Zulip):

(I know arguments and such make this impossible, I am not actually suggesting this)

RalfJ (Jan 15 2020 at 09:02, on Zulip):

I still think that it would be a very bad idea, very detrimental to unsafe code authors.

I'm not opposed to having some syntactic sugar that makes it easy to define an unsafe fn with unsafe body when you want to. But I think the current status is indeed more detrimental to unsafe code authors -- I have met plenty of people that fundamentally misunderstood the "proof obligation" nature of unsafe blocks because of the way unsafe fn makes everything inconsistent.

centril (Jan 15 2020 at 09:03, on Zulip):

(the = expr; stuff is intended as the sugar, e.g. unsafe fn foo() = unsafe { ... };)

Lokathor (Jan 15 2020 at 09:14, on Zulip):

@RalfJ the fact that rust does not let you even attempt to properly describe the proof obligations in a checked way is its own whole other problem

Lokathor (Jan 15 2020 at 09:15, on Zulip):

I think there's absolutely an educational gap when it comes to unsafe code

Lokathor (Jan 15 2020 at 09:18, on Zulip):

I don't think that making people fill their functions with more unsafe { ... } around expressions will fix that gap.

RalfJ (Jan 15 2020 at 16:24, on Zulip):

RalfJ the fact that rust does not let you even attempt to properly describe the proof obligations in a checked way is its own whole other problem

indeed it is, which is why I dont understand why you are even mentioning it

RalfJ (Jan 15 2020 at 16:24, on Zulip):

when I am talking about people misunderstanding unsafe, that has nothing to do with making rustc understand the involved proof obligations any better

Laurențiu Nicola (Jan 15 2020 at 17:10, on Zulip):

I still think that it would be a very bad idea, very detrimental to unsafe code authors.

ISTM it would allow unsafe code authors to make a cleaner separation between unsafe as in implementation details and unsafe as in a contract between an API and its users. That seems like a reasonable thing to have (at the cost of some verbosity), so I wouldn't call it _detrimental_.

Lokathor (Jan 16 2020 at 06:25, on Zulip):

(deleted)

Last update: May 26 2020 at 11:05UTC