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

Topic: meeting-2018-11-29


avadacatavra (Nov 29 2018 at 16:04, on Zulip):

Hello friends! Any agenda items?

Alan Jeffrey (Nov 29 2018 at 16:16, on Zulip):

One thing that came up in the representation of pointers...

Alan Jeffrey (Nov 29 2018 at 16:16, on Zulip):

the defns of "representation", "validity" and "safety".

Alan Jeffrey (Nov 29 2018 at 16:17, on Zulip):

If we're using the defns of https://www.ralfj.de/blog/2018/08/22/two-kinds-of-invariants.html then we should say so somewhere!

nikomatsakis (Nov 29 2018 at 16:17, on Zulip):

cc @WG-unsafe-code-guidelines

avadacatavra (Nov 29 2018 at 16:17, on Zulip):

@Alan Jeffrey sounds like something to pop in the introduction

Alan Jeffrey (Nov 29 2018 at 16:18, on Zulip):

Also, are we okay with representation depending on validity?

avadacatavra (Nov 29 2018 at 16:18, on Zulip):

which i can do

avadacatavra (Nov 29 2018 at 16:18, on Zulip):

i think representation and validity will be combined, but we wanted the discussions to be separate

nikomatsakis (Nov 29 2018 at 16:18, on Zulip):

I think that was the whole point of validity? (to help us figure out what repr optimizations we could do)

Nicole Mazzuca (Nov 29 2018 at 16:19, on Zulip):

I think validity on a single type level depends on representation

Nicole Mazzuca (Nov 29 2018 at 16:19, on Zulip):

and representation on a sum type level depends on validity of sub-types

nikomatsakis (Nov 29 2018 at 16:19, on Zulip):

I guess what I mean is that they are intertwined; e.g., we can optimize Option<&T> to use NULL because the repr invariant assures it can never be NULL

Nicole Mazzuca (Nov 29 2018 at 16:19, on Zulip):

(not the right word, but I can't think of a better one - member types, maybe?)

Alan Jeffrey (Nov 29 2018 at 16:20, on Zulip):

Yes, the problem is that validity of references includes being dereferenceable, so representation now depends on the state of all memory.

Nicole Mazzuca (Nov 29 2018 at 16:20, on Zulip):

no, validity depends on the state of all memory

Nicole Mazzuca (Nov 29 2018 at 16:21, on Zulip):

representation does not

nikomatsakis (Nov 29 2018 at 16:21, on Zulip):

I guess you could say that there is some subset of validity ... "representation validity" or something.

gnzlbg (Nov 29 2018 at 16:21, on Zulip):

I think that what @Alan Jeffrey meant here is that the definitions of the terms "representation", "validity", and "safety", should be in the introduction - otherwise it is very hard to follow along.

Nicole Mazzuca (Nov 29 2018 at 16:21, on Zulip):

@gnzlbg yeah

gnzlbg (Nov 29 2018 at 16:22, on Zulip):

This is independent from whether we decide to combine representation and validity or not

nikomatsakis (Nov 29 2018 at 16:22, on Zulip):

yes, makes sense, and it seems like it may take a bit of back and forth to settle precisely how they are layered :)

RalfJ (Nov 29 2018 at 16:22, on Zulip):

and some of this layering depends on decisions we have yet to make

avadacatavra (Nov 29 2018 at 16:22, on Zulip):

i'll try to get the intro submitted--it will take liberally from both gankro's and ralf's posts

Alan Jeffrey (Nov 29 2018 at 16:22, on Zulip):

@nikomatsakis yes, something like "bitstring validity" which just says whether a sequence of bits is possibly valid for T without looking at memory.

RalfJ (Nov 29 2018 at 16:22, on Zulip):

like, I know some people want to make &T valid only if it points to valid data

RalfJ (Nov 29 2018 at 16:23, on Zulip):

@nikomatsakis yes, something like "bitstring validity" which just says whether a sequence of bits is possibly valid for T without looking at memory.

I still claim this is not a useful notion and only confusing. in a stateful language such as Rust, all invariants, statements, things you can say may depend on memory. that's just something to get used to. if you dont like it, use Haskell. ;)

gnzlbg (Nov 29 2018 at 16:24, on Zulip):

I think it is worth to have some "loose" definitions for now, we can revisit them later, but it comes over and over again that discussions get mixed because we can tell these really appart

Alan Jeffrey (Nov 29 2018 at 16:24, on Zulip):

So a value of type &Twould be bitstring-valid if it's non-zero and a multiple of Ts alignment.

Nicole Mazzuca (Nov 29 2018 at 16:24, on Zulip):

I agree with @RalfJ here

RalfJ (Nov 29 2018 at 16:24, on Zulip):

and if you really insist, your "bitstring validity" is just "there exists a memory such that this is valid". there are no separate choices to be made.

Alan Jeffrey (Nov 29 2018 at 16:24, on Zulip):

The niche optimization just depends on bitstring validity.

Alan Jeffrey (Nov 29 2018 at 16:25, on Zulip):

So we'd have repr depending on "bitstring validity" rather than all of validity.

RalfJ (Nov 29 2018 at 16:25, on Zulip):

The niche optimization just depends on bitstring validity.

hm. I can see how you see it that way, though I do not think of it in these terms

nikomatsakis (Nov 29 2018 at 16:25, on Zulip):

@avadacatavra did we have an agenda?

avadacatavra (Nov 29 2018 at 16:25, on Zulip):

@nikomatsakis i wanted to see if anyone had agenda items

nikomatsakis (Nov 29 2018 at 16:26, on Zulip):

(I know I failed utterly to do the things I wanted to do last week, which I will blame on being laid out sick the last 2 days)

avadacatavra (Nov 29 2018 at 16:26, on Zulip):

Ok, let's back up a level

gnzlbg (Nov 29 2018 at 16:26, on Zulip):

I have one agenda item

gnzlbg (Nov 29 2018 at 16:27, on Zulip):

@avadacatavra please go over the agenda, we can discuss my item at the end if there is time (it's the bool stuff)

avadacatavra (Nov 29 2018 at 16:28, on Zulip):

Agenda:

nikomatsakis (Nov 29 2018 at 16:29, on Zulip):

is there nesting to that list ? :)

avadacatavra (Nov 29 2018 at 16:29, on Zulip):

is there nesting to that list ? :)

...i'm working on it....

RalfJ (Nov 29 2018 at 16:30, on Zulip):

:D

avadacatavra (Nov 29 2018 at 16:30, on Zulip):

/me thinks that was unnecessarily difficult

avadacatavra (Nov 29 2018 at 16:31, on Zulip):

Do we have any other repr writeups needed?

nikomatsakis (Nov 29 2018 at 16:31, on Zulip):

I sort of recall agreeing to do "enum"?

Alan Jeffrey (Nov 29 2018 at 16:31, on Zulip):

Pointers

nikomatsakis (Nov 29 2018 at 16:31, on Zulip):

but I didn't :P

RalfJ (Nov 29 2018 at 16:31, on Zulip):

https://github.com/rust-rfcs/unsafe-code-guidelines/issues?q=is%3Aissue+is%3Aopen+label%3Atopic-repr

RalfJ (Nov 29 2018 at 16:31, on Zulip):

references?

RalfJ (Nov 29 2018 at 16:31, on Zulip):

doesnt even have someone assigned yet

Alan Jeffrey (Nov 29 2018 at 16:31, on Zulip):

I got assigned it

gnzlbg (Nov 29 2018 at 16:31, on Zulip):

enums is the big one, the one from pointers, we might want to move it into int/fp/..., it might be "trivial"

RalfJ (Nov 29 2018 at 16:32, on Zulip):

and then I guess the other open issues should get an "postponed / open question" label or so?

Alan Jeffrey (Nov 29 2018 at 16:32, on Zulip):

https://github.com/asajeffrey/unsafe-code-guidelines/blob/repr-pointers/reference/src/representation/pointers.md

RalfJ (Nov 29 2018 at 16:32, on Zulip):

ah right we cannot assign alan because he's not a member of the repo or so? can we change that?^^

Alan Jeffrey (Nov 29 2018 at 16:33, on Zulip):

It got bogged down with discssions of basic defns.

nikomatsakis (Nov 29 2018 at 16:33, on Zulip):

I can fix that

nikomatsakis (Nov 29 2018 at 16:33, on Zulip):

@Alan Jeffrey what is your GH username?

gnzlbg (Nov 29 2018 at 16:33, on Zulip):

@Alan Jeffrey looks good, you might want to revise it now that we have hopefully clarified repr and validity, it should get a bit simpler if it only has to focus on repr, but don't throw the validity parts away, we'll need them soon :)

nikomatsakis (Nov 29 2018 at 16:33, on Zulip):

also,, @gnzlbg, I'll add you too

Alan Jeffrey (Nov 29 2018 at 16:33, on Zulip):

asajeffrey

avadacatavra (Nov 29 2018 at 16:34, on Zulip):

woo look at us accomplishing things!

nikomatsakis (Nov 29 2018 at 16:34, on Zulip):

you both need to confirm with this link

Nicole Mazzuca (Nov 29 2018 at 16:34, on Zulip):

oh I gotta go or miss my bus, o7

avadacatavra (Nov 29 2018 at 16:34, on Zulip):

ok, so it seems like things are on track with the repr writeups

RalfJ (Nov 29 2018 at 16:35, on Zulip):

any repr writeups reading for merging?

gnzlbg (Nov 29 2018 at 16:35, on Zulip):

layout of vectors maybe, there are a couple of open questions

nikomatsakis (Nov 29 2018 at 16:36, on Zulip):

I'm wondering if there is something we can say

nikomatsakis (Nov 29 2018 at 16:36, on Zulip):

about e.g. single variant structs

nikomatsakis (Nov 29 2018 at 16:36, on Zulip):

I sort of forget though, have to review

nikomatsakis (Nov 29 2018 at 16:36, on Zulip):

I feel like there was some basic minimum that a lot of folks rely on in practice anyhow, probably newtype layout

gnzlbg (Nov 29 2018 at 16:36, on Zulip):

there is an issue open about homogeneous structs, of which single variant are a subset

avadacatavra (Nov 29 2018 at 16:36, on Zulip):

I created an open-question label for things we want to revisit

Alan Jeffrey (Nov 29 2018 at 16:37, on Zulip):

I added https://github.com/rust-rfcs/unsafe-code-guidelines/issues/50

nikomatsakis (Nov 29 2018 at 16:37, on Zulip):

there is an issue open about homogeneous structs, of which single variant are a subset

yes but I think the single variant may be something we could agree on now

nikomatsakis (Nov 29 2018 at 16:37, on Zulip):

with homogeneity left for later

gnzlbg (Nov 29 2018 at 16:37, on Zulip):

@nikomatsakis do you mean saying something in the spirit of repr(transparent) ?

nikomatsakis (Nov 29 2018 at 16:37, on Zulip):

that was my impression at some point

RalfJ (Nov 29 2018 at 16:37, on Zulip):

@gnzlbg just for layout I assume, not for ABI

nikomatsakis (Nov 29 2018 at 16:37, on Zulip):

right

nikomatsakis (Nov 29 2018 at 16:37, on Zulip):

#[repr(transparent)] would extend it to ABI

nikomatsakis (Nov 29 2018 at 16:37, on Zulip):

it's certainly true now

RalfJ (Nov 29 2018 at 16:38, on Zulip):

so, you can transmute but not pass by value

nikomatsakis (Nov 29 2018 at 16:38, on Zulip):

and I can't imagine it ever not being true

nikomatsakis (Nov 29 2018 at 16:38, on Zulip):

but then I guess that's the question :)

gnzlbg (Nov 29 2018 at 16:38, on Zulip):

Is there a reason why saying that they have the same size and alignment is a bad idea?

nikomatsakis (Nov 29 2018 at 16:39, on Zulip):

I guess that sort of implies also that it must start at offset 0 :)

gnzlbg (Nov 29 2018 at 16:40, on Zulip):

but since it only has one element, there aren't any other offsets ? I don't recall if we allow repr(Rust) struct fields to start at a different offset than zero, probably we don't say anything about this anywhere, but in practice we don't

nikomatsakis (Nov 29 2018 at 16:40, on Zulip):

right we're talking about committing to it

nikomatsakis (Nov 29 2018 at 16:40, on Zulip):

anyway I'll maybe propose it

avadacatavra (Nov 29 2018 at 16:40, on Zulip):

sounds good to me--any further discussion can go in gh

gnzlbg (Nov 29 2018 at 16:40, on Zulip):

We could open an issue to see if anyone has anything against that: repr(Rust) struct with one field have the field at offset zero, or in general

avadacatavra (Nov 29 2018 at 16:41, on Zulip):

is that something that should have an rfc?

nikomatsakis (Nov 29 2018 at 16:41, on Zulip):

I was going to open a PR

nikomatsakis (Nov 29 2018 at 16:41, on Zulip):

and link to it from the issues

nikomatsakis (Nov 29 2018 at 16:41, on Zulip):

to get feedback

nikomatsakis (Nov 29 2018 at 16:41, on Zulip):

seems like a minor edit to the struct section

gnzlbg (Nov 29 2018 at 16:41, on Zulip):

that's even better

RalfJ (Nov 29 2018 at 16:41, on Zulip):

we already have an issue for this: https://github.com/rust-rfcs/unsafe-code-guidelines/issues/34

avadacatavra (Nov 29 2018 at 16:42, on Zulip):

ok, any other lingering things we should take care of in the repr discussion?

gnzlbg (Nov 29 2018 at 16:42, on Zulip):

bool

avadacatavra (Nov 29 2018 at 16:43, on Zulip):

@gnzlbg talk to me about bool

nikomatsakis (Nov 29 2018 at 16:43, on Zulip):

we have had some RFCs on the topic

gnzlbg (Nov 29 2018 at 16:43, on Zulip):

the T-lang and T-compiler teams committed already to one thing, but we might want to do something that's potentially incompatible to that decision

RalfJ (Nov 29 2018 at 16:43, on Zulip):

uh?

nikomatsakis (Nov 29 2018 at 16:43, on Zulip):

I don't really think we can do that :)

gnzlbg (Nov 29 2018 at 16:43, on Zulip):

basically the T-lang and T-compiler said that bool is equivalent to C _Bool

gnzlbg (Nov 29 2018 at 16:44, on Zulip):

and we might want to go over that and say that bool has a size of 1, 0 == true and 1 == false

avadacatavra (Nov 29 2018 at 16:44, on Zulip):

i may have done a poor job of summarizing consensus etc -- i'm totally open to revisions

nikomatsakis (Nov 29 2018 at 16:44, on Zulip):

is this sort of stronger than C _Bool, in theory?

gnzlbg (Nov 29 2018 at 16:44, on Zulip):

this wasn't raised in the issue, @rkruppe luckily remember it in the PR

gnzlbg (Nov 29 2018 at 16:45, on Zulip):

in theory it is incompatible, in practice right now it might not matter, because that's how it is in all platforms that Rust supports

RalfJ (Nov 29 2018 at 16:45, on Zulip):

so the concern here is that this will rule out porting Rust to platforms where C has a non-1-sized bool?

gnzlbg (Nov 29 2018 at 16:45, on Zulip):

no, that's something that we want to support

RalfJ (Nov 29 2018 at 16:45, on Zulip):

(I thought I read somewhere than next-gen C or C++ will specify 0 and 1 for false and true but I might hallucinate)

nikomatsakis (Nov 29 2018 at 16:45, on Zulip):

this wasn't raised in the issue, @rkruppe luckily remember it in the PR

(which PR?)

avadacatavra (Nov 29 2018 at 16:45, on Zulip):

@nikomatsakis i think the int/fp pr

nikomatsakis (Nov 29 2018 at 16:45, on Zulip):

ok

gnzlbg (Nov 29 2018 at 16:46, on Zulip):

https://github.com/rust-rfcs/unsafe-code-guidelines/pull/49#discussion_r236762111

gnzlbg (Nov 29 2018 at 16:46, on Zulip):

we want people to use bool on C FFI, we don't want people to create a c_bool type due to "portability paranoia", so the goals are aligned with the T-Compiler and T-lang decisions

gnzlbg (Nov 29 2018 at 16:47, on Zulip):

we also might want to guarantee that bool has size 1, and its valid values as integers,

gnzlbg (Nov 29 2018 at 16:47, on Zulip):

and we don't want to break FFI with platforms in which C _Bool is different than ours

nikomatsakis (Nov 29 2018 at 16:47, on Zulip):

yes ok I just skimmed it

gnzlbg (Nov 29 2018 at 16:47, on Zulip):

so one idea here was to, if Rust ever supports such a platform, it could warn/error that bool is not a proper c type

nikomatsakis (Nov 29 2018 at 16:48, on Zulip):

I suspect this same thing will arise in other contexts

gnzlbg (Nov 29 2018 at 16:48, on Zulip):

if we want to say bool == _Bool, then we can't say much

nikomatsakis (Nov 29 2018 at 16:48, on Zulip):

it feels like there is a kind of "general rule of thumb" we should settle

gnzlbg (Nov 29 2018 at 16:48, on Zulip):

because _Bool is pretty much _implementation-defined_ in the C standard

gnzlbg (Nov 29 2018 at 16:49, on Zulip):

C20 and C++20 do want to guarantee that 0 == false and 1 == true, and maybe some day that it has size 1

RalfJ (Nov 29 2018 at 16:49, on Zulip):

so why can't we just stick to "like C"?

nikomatsakis (Nov 29 2018 at 16:49, on Zulip):

do you want me to raise this in a lang team meeting? tbh I don't remember what people felt from those prior discussions. I have a sense that the feeling was "let's define to be something useful" -- I think there is an interesting argument about which is the most "useful" here

RalfJ (Nov 29 2018 at 16:49, on Zulip):

for repr: size same as C
for validity: the two bit patterns are the same as C's

nikomatsakis (Nov 29 2018 at 16:49, on Zulip):

so why can't we just stick to "like C"?

I think the reason is that people find C frustratingly vague

nikomatsakis (Nov 29 2018 at 16:50, on Zulip):

and wind up in practice relying on stronger things

nikomatsakis (Nov 29 2018 at 16:50, on Zulip):

at least that's what I got from the PR comments

RalfJ (Nov 29 2018 at 16:50, on Zulip):

I find all of this repr discussion frustratingly vague :P

RalfJ (Nov 29 2018 at 16:50, on Zulip):

we can document what this means for the popular platforms

gnzlbg (Nov 29 2018 at 16:50, on Zulip):

I don't know, I think it is ok to say "like _Bool" now, and resolve this as we go

avadacatavra (Nov 29 2018 at 16:50, on Zulip):

is this something i should just put as a controversy?

gnzlbg (Nov 29 2018 at 16:50, on Zulip):

but if we want to guarantee anything else, we probably need to involve T-lang and T-compiler somehow

avadacatavra (Nov 29 2018 at 16:51, on Zulip):

and document what we've talked about here

nikomatsakis (Nov 29 2018 at 16:51, on Zulip):

seems ok

gnzlbg (Nov 29 2018 at 16:51, on Zulip):

I think maybe me and @Gankro and @rkruppe could go over this again, and prepare a proposal, and discuss it in the next meeting

nikomatsakis (Nov 29 2018 at 16:51, on Zulip):

I think we can either say "like C" and have a separation section that says "on popular platforms, that means this"

nikomatsakis (Nov 29 2018 at 16:51, on Zulip):

and say "rust doesn't support other platforms yet so that's not formally decided"

avadacatavra (Nov 29 2018 at 16:51, on Zulip):

ok i'll revise the pr

gnzlbg (Nov 29 2018 at 16:51, on Zulip):

yes, the docs currently say that bool has size 1, but they are not "normative"

nikomatsakis (Nov 29 2018 at 16:51, on Zulip):

but yeah it feels like this will come up (e.g., with fn pointers) in a number of places -- or maybe just a handful :)

avadacatavra (Nov 29 2018 at 16:52, on Zulip):

so, unless there's anything else,are we ready to chat about validity

RalfJ (Nov 29 2018 at 16:52, on Zulip):

yay :D

RalfJ (Nov 29 2018 at 16:52, on Zulip):

unfortunately I have pretty much 0 time for, uh, about a week...

gnzlbg (Nov 29 2018 at 16:52, on Zulip):

@avadacatavra state like _Bool in the PR, that's the safe bet, I'll open an issue just about this, and ping the relevant people, we should just resolve this before the RFC

avadacatavra (Nov 29 2018 at 16:52, on Zulip):

@gnzlbg thanks :)

nikomatsakis (Nov 29 2018 at 16:53, on Zulip):

what exactly did we want to say about "validity"?

avadacatavra (Nov 29 2018 at 16:53, on Zulip):

@RalfJ will you be at all hands?

avadacatavra (Nov 29 2018 at 16:53, on Zulip):

@nikomatsakis mostly i want to see if we've started discussing it

RalfJ (Nov 29 2018 at 16:53, on Zulip):

@avadacatavra which one? in Feb in Berlin, yes

avadacatavra (Nov 29 2018 at 16:53, on Zulip):

and if we haven't, what's our starting point

nikomatsakis (Nov 29 2018 at 16:53, on Zulip):

ok

avadacatavra (Nov 29 2018 at 16:53, on Zulip):

@avadacatavra which one? in Feb in Berlin, yes

i meant the one next week

RalfJ (Nov 29 2018 at 16:53, on Zulip):

but not the mozilla one, no

RalfJ (Nov 29 2018 at 16:54, on Zulip):

I have to write some documents for job applications... and I hate every minute of it^^

avadacatavra (Nov 29 2018 at 16:55, on Zulip):

Speaking of all hands:

gnzlbg (Nov 29 2018 at 16:55, on Zulip):

The layout of vectors should be finished, and can be merged.

nikomatsakis (Nov 29 2018 at 16:55, on Zulip):

yes, I'll be there next week, and I am sure we won't be avail for meeting...

nikomatsakis (Nov 29 2018 at 16:55, on Zulip):

congrats re: move (I guess?) =)

avadacatavra (Nov 29 2018 at 16:55, on Zulip):

So, validity. Where will we start? (and then we'll adjorn)

nikomatsakis (Nov 29 2018 at 16:55, on Zulip):

I guess we mostly need a PR to "kick off" the conversation

avadacatavra (Nov 29 2018 at 16:56, on Zulip):

/me will be in your timezone!

gnzlbg (Nov 29 2018 at 16:56, on Zulip):

validity of ints etc. is probably the easiest place to start

nikomatsakis (Nov 29 2018 at 16:56, on Zulip):

what would be the "issues"

gnzlbg (Nov 29 2018 at 16:56, on Zulip):

all bit patterns are valid

Alan Jeffrey (Nov 29 2018 at 16:56, on Zulip):

https://github.com/rust-rfcs/unsafe-code-guidelines/issues/50 might be a good start.

gnzlbg (Nov 29 2018 at 16:56, on Zulip):

validity of references is thorny, because they interact with pointers, niches, enum optimizations, DSTs, ...

nikomatsakis (Nov 29 2018 at 16:56, on Zulip):

seems like @RalfJ has some instinct for what has additional "validity" requires beyond the bit-pattern rules

nikomatsakis (Nov 29 2018 at 16:56, on Zulip):

I imagine they can rattle off a list for us :)

gnzlbg (Nov 29 2018 at 16:56, on Zulip):

we probably need the enum layout part merged first before starting with validity of references

avadacatavra (Nov 29 2018 at 16:57, on Zulip):

@RalfJ would you be able to open a PR to open up the discussion?

avadacatavra (Nov 29 2018 at 16:57, on Zulip):

i'm happy to start discussion in issues before we finalize all writeup merges

RalfJ (Nov 29 2018 at 16:57, on Zulip):

validity of ints etc. is probably the easiest place to start

oh no ints are subtle

RalfJ (Nov 29 2018 at 16:57, on Zulip):

because "bit patterns" include uninitialized data

RalfJ (Nov 29 2018 at 16:57, on Zulip):

and we have to talk about whether we want to allow uninitialized ints

nikomatsakis (Nov 29 2018 at 16:57, on Zulip):

why is it always the things that seem easiest that are the hardest.

Alan Jeffrey (Nov 29 2018 at 16:57, on Zulip):

Does "validity" include discussions of provenance?

avadacatavra (Nov 29 2018 at 16:58, on Zulip):

@RalfJ sounds good--pick a starting point you think is better :D

RalfJ (Nov 29 2018 at 16:58, on Zulip):

Does "validity" include discussions of provenance?

I hope not :D

avadacatavra (Nov 29 2018 at 16:58, on Zulip):

@Alan Jeffrey do we have an issue about provenance

RalfJ (Nov 29 2018 at 16:58, on Zulip):

@RalfJ sounds good--pick a starting point you think is better :D

structs are easy

RalfJ (Nov 29 2018 at 16:58, on Zulip):

they are valid if all their fields are valid

avadacatavra (Nov 29 2018 at 16:58, on Zulip):

maybe that should be a proposed topic

RalfJ (Nov 29 2018 at 16:58, on Zulip):

I hope enums will be easy, too^^

avadacatavra (Nov 29 2018 at 16:58, on Zulip):

Sounds good. So, this is what I have as a summary...

RalfJ (Nov 29 2018 at 16:58, on Zulip):

@RalfJ would you be able to open a PR to open up the discussion?

what would that PR do?

nikomatsakis (Nov 29 2018 at 16:58, on Zulip):

that PR would propose the topics for further discussion

nikomatsakis (Nov 29 2018 at 16:58, on Zulip):

lay out common definitions

RalfJ (Nov 29 2018 at 16:59, on Zulip):

I dont think I should commit to doing anything before Wed or so

gnzlbg (Nov 29 2018 at 16:59, on Zulip):

state questions of things to resolve, tricky things, etc.

nikomatsakis (Nov 29 2018 at 16:59, on Zulip):

probably not urgent as we still haven't really wrapped up validity

RalfJ (Nov 29 2018 at 16:59, on Zulip):

I really need to get these documents written^^

nikomatsakis (Nov 29 2018 at 16:59, on Zulip):

though it'd be nice to do so by next meeting

RalfJ (Nov 29 2018 at 16:59, on Zulip):

but yeah sure I can write that thing, eventually

nikomatsakis (Nov 29 2018 at 16:59, on Zulip):

maybe one of us can try to draft up an outline of interesting questions and run it by you for feedback?

RalfJ (Nov 29 2018 at 17:00, on Zulip):

I guess I can look at the repr one to see how they look like?

avadacatavra (Nov 29 2018 at 17:00, on Zulip):

1. Document what we've said about bool
2. I will do the intro
3. Niko will do enum
4. We'll try to get all the validity stuff merged
5. Ralf will start the validity discussion with a PR next week (possibly with assistance)
6. No meeting next week

RalfJ (Nov 29 2018 at 17:00, on Zulip):

though it'd be nice to do so by next meeting

that's in 2 weeks, right? easy

nikomatsakis (Nov 29 2018 at 17:00, on Zulip):

I guess I can look at the repr one to see how they look like?

yeah https://github.com/rust-rfcs/unsafe-code-guidelines/pull/5

avadacatavra (Nov 29 2018 at 17:01, on Zulip):

/me disappears

gnzlbg (Nov 29 2018 at 17:01, on Zulip):

i can't next week :snowboarder:

avadacatavra (Nov 29 2018 at 17:01, on Zulip):

/me will try to open some prs/edit them tonight/tomorrow

nikomatsakis (Nov 29 2018 at 17:01, on Zulip):

I'll delete from the calendar item

RalfJ (Nov 29 2018 at 17:02, on Zulip):

@nikomatsakis so you say single-field structs are trivial, but shouldnt ZST structs be even trivialler?

nikomatsakis (Nov 29 2018 at 17:02, on Zulip):

heh you'd think so

gnzlbg (Nov 29 2018 at 17:02, on Zulip):

@RalfJ not in C FFI

nikomatsakis (Nov 29 2018 at 17:02, on Zulip):

and really one depends on the other

nikomatsakis (Nov 29 2018 at 17:02, on Zulip):

i.e., is it "single-field plus ZSTs?"

RalfJ (Nov 29 2018 at 17:02, on Zulip):

yeah

RalfJ (Nov 29 2018 at 17:02, on Zulip):

@RalfJ not in C FFI

we can leave that part open

RalfJ (Nov 29 2018 at 17:03, on Zulip):

but we are unliked to change what repr(C) does

RalfJ (Nov 29 2018 at 17:03, on Zulip):

so we might as well document it

nikomatsakis (Nov 29 2018 at 17:03, on Zulip):

I may decide it's not worth it, but it does feel like this is a real question that arises and I don't think there's really much dispute about the answer, just hesitation about how to word it

RalfJ (Nov 29 2018 at 17:03, on Zulip):

and as niko said it's kind of needed for single-field stuff

RalfJ (Nov 29 2018 at 17:03, on Zulip):

so @nikomatsakis should I mark both ZST and single-field as "writeup needed"?

nikomatsakis (Nov 29 2018 at 17:04, on Zulip):

I think so

gnzlbg (Nov 29 2018 at 17:04, on Zulip):

i gotta run, I guess it might be easier to discuss it with a PR that proposes what to do

gnzlbg (Nov 29 2018 at 17:04, on Zulip):

or in an issue explaining the problems

RalfJ (Nov 29 2018 at 17:05, on Zulip):

ack

RalfJ (Nov 29 2018 at 17:05, on Zulip):

see you!

Alan Jeffrey (Nov 29 2018 at 17:06, on Zulip):

I submitted https://github.com/rust-rfcs/unsafe-code-guidelines/pull/51

Last update: Nov 20 2019 at 13:10UTC