add rough minutes from last two lang team meetings

lang-team/2015-07-16.md

@@ -0,0 +1,67 @@
+# Agenda
+
+- Triage
+  - Triage of rfcs PRs
+  - Triage of rust PRs + issues too?
+- FCP RFCs
+- RFC Roundup
+- Specialization
+- Dynamic Drop
+- Efficient Inheritance
+- dropck
+- &mut T -> &Cell<T> brainteaser
+- https://github.com/rust-lang/rfcs/pull/1177
+
+# Action Items
+
+- Close #1201 (nmatsakis), cite prior RFC #55 
+- Close #1154, cite issue #294
+- Merge #873
+- Close #1150 (nmatsakis)
+- IndexSet => FCP
+
+# Triage
+
+- https://github.com/rust-lang/rfcs/pull/1209
+  - assigned to nmatsakis
+  - nominate for FCP
+
+- https://github.com/rust-lang/rfcs/pull/1201
+  - naked functions
+  - precedent: https://github.com/rust-lang/rfcs/pull/55
+  - conclusion:
+    - let's close as premature, low-level stabilization 
+
+- https://github.com/rust-lang/rfcs/pull/1154
+  - close under #294
+
+- https://github.com/rust-lang/rfcs/pull/1129
+
+- https://github.com/rust-lang/rfcs/pull/873
+  - merge (right?)
+
+# Rust issues
+
+ - big picture: in general, assume that PR's with known breaking
+   changes of the form "X becomes a compile-time error" simply have to
+   go through a warning cycle before the hard error is turned on.
+
+# FCPs
+
+- macros in types https://github.com/rust-lang/rfcs/pull/873
+  - feature-gate period should provide time for us to hammer out issues here
+
+- "'_" https://github.com/rust-lang/rfcs/pull/1177
+   - some open questions:
+     - `'_` in a return type, should it be always fresh?
+     - `'_` in a trait object bound, needs more discussion
+     - could use it to signal when elision is hiding regions
+       - but without a lint people will probably not do that
+
+- dropck
+  - try to use an unsafe attribute temporarily
+  - run experiment: add this attribute to all collections, run crater
+
+- efficient inheritance
+  - met with jdm
+  - design seems good

lang-team/2015-07-23.md

@@ -0,0 +1,112 @@
+# 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<T> brainteaser
+
+# Action Items (also carry over from last week)
+
+- Close #1216 (nmatsakis)
+- FCP #1219 (nmatsakis)
+
+# Triage of new RFCs
+
+- RFC https://github.com/rust-lang/rfcs/pull/1216
+
+nmatsakis: seems like not enough benefit for the complexity
+nmatsakis: modeling with an explicit enum feels like... not bad
+
+- RFC https://github.com/rust-lang/rfcs/pull/1219
+
+- Issue https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/pull/26421
+  - waiting for PR author to impl a warning cycle
+
+- PR https://github.com/rust-lang/rust/pull/25509
+
+- Issue https://github.com/rust-lang/rust/issues/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 => _,
+    }
+}
+```
+
+  - kind of a mess of problems, unclear what best solution is
+  - but we should settle on some rules, make an RFC, and then have a warning cycle
+
+  - nmatsakis: I feel if both of these are accepted then they should be equivalent:
+
+```
+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
+