Agenda

Triage
- Triage of rfcs PRs
- Triage of rust PRs + issues too?
Triage policy: Is our domain really solely RFCs ?
- Do "course corrections" go through RFC process? And Breaking-change bug-fixes?
&mut T -> &Cell brainteaser

Action Items (also carry over from last week)

nmatsakis: seems like not enough benefit for the complexity nmatsakis: modeling with an explicit enum feels like... not bad

RFC rust-lang/rfcs#1219
Issue rust-lang/rust#27060
- not specific to SIMD
- seems like we would ideally disallow references into packed structures
- or make them unsafe
- could also feature-gate repr(packed), at least for now
- if we made it unsafe, interesting ramifications for fields-in-traits, since they would have to point at an aligned field or else be declared unsafe
- next step: do a crater run where #[repr(packed)] is feature-gated
Issue rust-lang/rust#26952
- nmatsakis: I've been investigating regressions with brson, there was one that I didn't know cause of, might be related to this
PR rust-lang/rust#26421
- waiting for PR author to impl a warning cycle
PR rust-lang/rust#25509
Issue rust-lang/rust#20489
- we do not enforce any limits on the types used in patterns
- do not have to impl PartialEQ etc
- has impliciations for exhaustiveness as well, e.g.:

const TRUE: bool = true;
const FALSE: bool = false;

fn main() {
    match true { 
        TRUE => 1,
        FALSE => 2,
    };
}

this doesn't work with associated constants though
special case (static error check) rule rejecting NaN but this won't work with assoc constants

trait Constant {
    const Foo: f32;
}

fn foo<T:Constant>(x: f32) {
    match x {
        T::Foo => _,
    }
}

match x {
    CONSTANT => ... 
}

if x == CONSTANT {
    ...
}

pnkfelix: we could use Eq to ensure that you don't match on floats
pnkfelix: (but there is a quibble about how to handle ranges -- match f32 { lo...hi => ... } should still be okay)
if we don't want arbitrary code to execute, and we respect the principle above, we have to prohibit constants of non-builtin-types. This may be a big breaking change.
Next step: crater run to see what breaks when types are restricted to tuples of builtin types
&mut T -> &Cell<T> brainteaser:
- huon: is this a safe transformation?
- nmatsakis: I believe it is ok. Reasoning:
  - for duration of the &mut loan, nobody else can read it
  - once you're &Cell<T> is finished, it goes back to its original status
- pnkfelix: what about *mut -> &Cell<T>?
- conclusion: not safe in general because
  - (a) you don't know that the *mut is valid for the lifetime
  - (b) *mut could be accessed by another thread
  - (c) or uninitialized