Skip to content
This repository has been archived by the owner on Oct 9, 2018. It is now read-only.

Latest commit

 

History

History
147 lines (105 loc) · 6.97 KB

2015-02-10.md

File metadata and controls

147 lines (105 loc) · 6.97 KB

Agenda 2015-02-10

Attending

brson, pnkfelix, huon, larsberg, nmatsakis, pcwalton, aturon, acrichto, nrc, steveklabnik, erickt

Status

  • brson: installer upgrades
  • acrichto: std::net, std::hash, I/O
  • pnkfelix: Sound Generic Drop
  • aturon: std::process, final stabilization for a few modules, release announcement
  • nmatsakis: ICEs, variance, some other stuff
  • nrc: RFCs, assoc types/HRL things, compiler/driver API

Action Items

  • pnkfelix: will amend RFC 320 and feature-gate unsafe_no_drop_flag
  • aturon: merge rust-lang/rfcs#809

Friend of the Tree - Jonathan Reem (reem)

Jonathan Reem has been making an impact on Rust since May 2014. His primary contribution has been as the main author of the prominent Iron web framework, though he has also created several other popular projects including the testing framework stainless. His practical experience with these projects has lead to several improvements in upstream rust, most notably his complete rewrite of the TaskPool type. Reem is doing everything he can to advance the Rust cause.

Feature gating unsafe_no_drop_flag

  • pnkfelix: Don't have unsafe_no_drop_flag feature gated. I'm assuming we want to do it, but what's the best route? Should I just attach it to an RFC? Or new one?
  • brson: Amend.
  • nmatsakis: Not a separate RFC. Doesn't feel that big.
  • pnkfelix: Alternatively - can I just do it? If we all agree, we can just make the amendment, merge it, and do it.
  • brson: Just do it.
  • pnkfelix: Will do!
  • nmatsakis: There's an issue for feature-gating random attributes. Put it in there.

Fallout of box rfc

rust-lang/rust#22086

  • pnkfelix: Box rfc proposing two things. First, protocol for placement_in (in the RFC). That's not what I want to talk about - not important for 1.0. The important part for now is there's also a proposed overload for the box operator to infer the kind of things to create via the box from the expression's context. Determining from the expected return type what kind of box to create. Sounded fantastic! But, if you're using a box expression on an unsized type (notably box of trait), the system just can't handle it. Type inference can't make the two sides work out. They clash. Niko and I discussed it a bit, but there's no clear solution. What I do in the PR is just to make people add type ascriptions. But those aren't in the compiler yet.
fn foo() -> Box<Trait> {
    box ... // implicit coercion to Box<Trait>
}
  • pnkfelix: The RFC (809) has an appendix B with a longer description of the instances. Obvious one is this:

pub type BoxFn<'a> = Box<Fn() + 'a>;
  • pnkfelix: This works today.
  • brson: Behind a feature gate?
  • pnkfelix: Yes. If it lands, I'd keep it there, too, for the next release. Question is if we want to incur the cost imposed here:
// This works today
pub fn coerce<'a, F>(f: F) -> BoxFn<'a> where F: Fn(), F: 'a {   box  f   }

/// after desugaring, it stops working.  But these continue to work:
pub fn coerce<'a, F>(f: F) -> BoxFn<'a> where F: Fn(), F: 'a { let b: Box<_> = box_!( f ); b }
pub fn coerce<'a, F>(f: F) -> BoxFn<'a> where F: Fn(), F: 'a { Box::new( f ) }
// (This one assumes PR 22012 has landed)
pub fn coerce<'a, F>(f: F) -> BoxFn<'a> where F: Fn(), F: 'a { box_!( f ) as BoxFn }
  • pnkfelix: The top one is the one that stops working. Usually fixed the fallout by doing Box::new.

samples of fallout: https://github.com/pnkfelix/rust/commit/c95ed2eba71f53df0b56999e49431d961073b7a3

https://github.com/pnkfelix/rust/commit/d9dabc30c6b0dff691ef53ad958453cc0d76ba62

  • pnkfelix: Also haven't measured the perf of the compiler with the desugaring instead of the intrinsic support. May cause a speed hit for bootstrapping because there are extra nodes for every box expression. Not too concerned. I'm more asking: does this block even landing it? If there are objections, then we need to do more work on this.
  • brson: This seems experimental; it's behind a feature gate; we should keep moving forward on it.
  • aturon: Yup.
  • nmatsakis: I'd even say we should try to land it now, because then we can start working on the extensions & improvements.
  • pnkfelix: Then I'll keep moving forward with this!
  • brson: What about the RFC? Merge it?
  • pnkfelix: I did just change the syntax for placement_in. It's a point of contention, but I did see one proposal I really liked, so I just merged it in. The old one was:
Orignal placement-box:
box (PLACE-EXPR) VALUE-EXPR
has issues with ambiguities e.g. box (intended-value-expr...)

Original new proposal:
box VALUE-EXPR
in (PLACE-EXPR) VALUE-EXPR

New new proposal:
in PLACE-EXPR { BLOCK-CONTENTS }
  • pnkfelix: I'd like to land this in some form and then let the bikeshedding commence. I'd like to get it off a branch, get libraries using it for real feedback, etc.
  • aturon: Agreed. Until we use it in practice, we won't really know what syntax is most ergonomic. Can merge the RFC with that caveat.
  • brson: Who will summarize & merge?
  • nmatsakis: I will.

Feature gating unused attributes

rust-lang/rfcs#572

  • nrc: Uncontroversial; just future-proofing. But wanted to encourage more people to look at it, as there haven't been many comments, especially from core team. I think it's ready to go.

sizeof / alignof RFC

rust-lang/rfcs#591

  • nrc: size_of, align_of, etc. Almost ready to go. Current state of where it's at is that we will postpone type_of, but add size_of, align_of, and offset_of. Just a heads-up.
  • huonw: They're reserved already.
  • nmatsakis: On whether we can do these as an intrinsic or not, I don't know how to do that for offset_of.

Array pattern adjustments

rust-lang/rfcs#495

  • nmatsakis: Also wanted to try to get more comments on something. This pares down array patterns so they match on fixed-length arrays, primarily. I've been uncomfortable with array patterns, and this is the obvious conclusion of that.
  • pcwalton: Wouldn't block 1.0 on this. But I'd take it, if it gets done.
  • brson: I'm in favor of being conservative about our complex pattern matching.
  • aturon: Agreed. I like being more conservative.
  • nmatsakis: It is a bit odd that we currently have patterns that match against slices. Anyway, feel free to comment!

Servo status

  • larsberg: Finishing last android linking error, and then we'll move to Rust from last Sunday! We've pulled in a lot of breaking changes. We went through about 9 Rust snapshots in week...
  • larsberg: After this, we'll be basically caught up with Rust!