Stream: t-lang/wg-unsafe-code-guidelines

Topic: rename working group


gnzlbg (Jul 30 2019 at 16:49, on Zulip):

We've talked about this before, but what's the purpose of the working group and how does the name reflect that ?

"Unsafe code guidelines" reads as if the goal and purpose of the working group was to write down some guidelines for unsafe code, yet I don't think we have written a single guideline anywhere yet. Looking at the documents, we have defined the layout of Rust types, and provided layout guarantees, and in the issues, PRs and WIP documents, we are now dealing with what is the value representation of Rust types, which value representations are allowed, and which optimizations are guaranteed to happen for invalid value representations. There are also documents about an aliasing model, a memory model, and some do mention operational semantics, etc.

None of these look like "guidelines" at all, at least, not in the sense of, for example, the "API guidelines", which users are safe to just ignore. From the POV of releasing a first RFC at some point, "UCG RFC" would be a weird title if the document does not contain any guidelines at all.

I don't really know how we could give any guidelines to unsafe code, without a formal spec backing those up, but everything that has happened here does look like the first little steps towards a formal spec for Rust.

cc @nikomatsakis

RalfJ (Jul 30 2019 at 18:26, on Zulip):

maybe UCG is for "Unsafe Code Group"? ;)

Jake Goulding (Jul 30 2019 at 19:10, on Zulip):

PR WIP API POV RFC UCG RFC

Jake Goulding (Jul 30 2019 at 19:12, on Zulip):

I feel like working groups should have an end goal and be disbanded when the goal is achieved. With that view, the guidelines would answer the question "how can I write safe unsafe Rust?".

There's indeed a lot of steps from A to B.

Jake Goulding (Jul 30 2019 at 19:16, on Zulip):

But having a specific goal can allow you to evaluate if a given point falls within the purview of the working group

centril (Jul 30 2019 at 21:23, on Zulip):

I'd rename the WG to "The machinists" ;)

RalfJ (Jul 30 2019 at 21:37, on Zulip):

the specific goal could be a spec for unsafe code. "UCS WG"?

Lokathor (Jul 31 2019 at 02:44, on Zulip):

I don't know how you write your unsafe code, but simply specifying all you can is very literally the only thing that all the unsafe coders I know need

Lokathor (Jul 31 2019 at 02:45, on Zulip):

People interested in unsafe code just need a clear set of "physics" for what goes on in rust when you step behind the curtain, and they'll do all the rest on their own quite well

Tom Phinney (Jul 31 2019 at 05:34, on Zulip):

^^ If that's the case, then perhaps we should rename it "The Avoiding-UB Working Group" because that's the primary "physics" that they need to deal with when they "step behind the curtain".

RalfJ (Jul 31 2019 at 07:02, on Zulip):

or maybe just the "UB working group" and then people just have to avoid us :P

RalfJ (Jul 31 2019 at 07:05, on Zulip):

however I think the WG is actually broader than that (though my own focus is almost entirely on UB); specifying what we guarantee about data type layout is not directly about specifying UB.

Lokathor (Jul 31 2019 at 07:46, on Zulip):

Yeah I think that all the layout work is an important first step but there's definitely later steps as well.

gnzlbg (Jul 31 2019 at 07:47, on Zulip):

the specific goal could be a spec for unsafe code.

I don't know how to write a spec for unsafe Rust that does not also produce a spec for safe Rust, and hence, Rust itself

gnzlbg (Jul 31 2019 at 07:49, on Zulip):

Tom Phinney 7:34 AM
^^ If that's the case, then perhaps we should rename it "The Avoiding-UB Working Group" because that's the primary "physics" that they need to deal with when they "step behind the curtain".

Once you add multiple-threads, then you need a memory model to avoid UB around atomics, etc... The "repo" was actually called "memory-model" before

gnzlbg (Jul 31 2019 at 07:50, on Zulip):

FWIW I think that what we need is a language spec for Rust, for where "what is unsafe code allowed to do" can be derived

gnzlbg (Jul 31 2019 at 07:51, on Zulip):

Coming up with a language spec is an incremental and iterative process, and we are kind of focusing as "what guarantees can we provide to unsafe code so that it can answer some question about whether the code is correct"

gnzlbg (Jul 31 2019 at 07:53, on Zulip):

right now we don't even say whether creating an uninitialized 'u8' is ok, and some people want guarantees about multi-threaded code, signal handlers, data-races, aliasing, ....
by the time we are able to provide most of those guarantees, a formal spec will have to exist in some form

RalfJ (Jul 31 2019 at 08:03, on Zulip):

the specific goal could be a spec for unsafe code.

I don't know how to write a spec for unsafe Rust that does not also produce a spec for safe Rust, and hence, Rust itself

agreed. it's just that most of the spec for safe Rust is "rather obvious". hence I think it is useful to emphasize the "unsafe" or "UB" aspect of our work.

gnzlbg (Jul 31 2019 at 08:49, on Zulip):

The ISO C++ committe has a study group (SG12) called the Undefined Behavior Study Group (SG12) whose goal is to remove undefined / unspecified behavior from the spec. So maybe we are something like that, in which we try to remove unspecified and undefined behavior from the reference.

RalfJ (Jul 31 2019 at 08:54, on Zulip):

I see our job more as defining what exactly is UB and what is not

RalfJ (Jul 31 2019 at 08:54, on Zulip):

cutting down the amount of UB would be a second step, after we know better which UB we got

gnzlbg (Jul 31 2019 at 08:56, on Zulip):

i see going from unspecified to explicitly UB an improvement

gnzlbg (Jul 31 2019 at 08:56, on Zulip):

so I suppose we agree

centril (Jul 31 2019 at 17:20, on Zulip):

however I think the WG is actually broader than that (though my own focus is almost entirely on UB); specifying what we guarantee about data type layout is not directly about specifying UB.

This is why I somewhat jokingly suggested "The machinists" because this WG is mostly about advising the language team on the spec of the abstract machine.

centril (Jul 31 2019 at 17:21, on Zulip):

and guidelines re. unsafe fall out from that

Tom Phinney (Jul 31 2019 at 17:42, on Zulip):

This is why I somewhat jokingly suggested "The machinists" because this WG is mostly about advising the language team on the spec of the abstract machine.

t-lang/wg-abstract-machine would span all the edge cases (UB, layout, multi-thread) that we're discussing here, and undoubtedly others that we haven't yet considered. It also would mandate that some attention be given to documenting the more-obvious parts of the Rust abstract machine, but 1) that's an eventual requirement for a complete specification of Rust, and 2) much of that can probably be lifted from similar efforts for other languages.

rkruppe (Jul 31 2019 at 17:46, on Zulip):

Considering how much trouble we've had getting write-ups done so far, I am somewhat skeptical of taking on more "busy work" like bikeshedding the best way to write up operational semantics that say eg 1 + 1 does what one expects

RalfJ (Jul 31 2019 at 18:03, on Zulip):

agreed @rkruppe, but I still like "Rust Abstract Machine WG", as long as we make sure people still ping us when UB questions come up.

RalfJ (Jul 31 2019 at 18:03, on Zulip):

of course, the main reason I like it is that it entrnches my agenda of putting the abstract machine first, not the set of optimizations that can be performed. ;)

gnzlbg (Jul 31 2019 at 18:08, on Zulip):

I am somewhat skeptical of taking on more "busy work" like bikeshedding the best way to write up operational semantics that say eg 1 + 1 does what one expects

gnzlbg (Jul 31 2019 at 18:09, on Zulip):

we wouldn't take that work yet, we would punt it to some time point in the future, in the same way we avoided validity while discussing layout

Lokathor (Aug 01 2019 at 03:43, on Zulip):

"The RAM WG", perfect

gnzlbg (Aug 02 2019 at 13:11, on Zulip):

"Rust Abstract Machine WG"

That sounds good to me.

gnzlbg (Aug 02 2019 at 13:11, on Zulip):

wg-abstract-machine or similar as short

Last update: Nov 20 2019 at 12:10UTC