2014-12-30.md

Agenda 2014-12-30

• stability attribute changes (brson) rust-lang/rfcs#507
• fott (aturon)
• impl-trait-for-trait RFC rust-lang/rfcs#546

Attending

aturon, brson, nmatsakis, steveklabnik, nrc

Status

• brson: deploying combined installer automation, beta channel automation, refreshing feature staging patch
• aturon: path implementation, int/uint issues, stabilization
• nrc: various syntax things, resolve things, etc.

Action Items

Friend of the Tree

This is a belated recognition of Kevin Ballard (aka @kballard, aka Eridius) as a friend of the tree. Kevin put a lot of work into Unicode issues in Rust, especially as related to platform-specific constraints. He wrote the current path module in part to accommodate these constraints, and participated in the recent redesign of the module. He has also been a dedicated and watchful reviewer. Thanks, Kevin, for your contributions!

impl-trait-for-trait

rust-lang/rfcs#546

• nmatsakis: want to make it so if you have a trait then the corresponding trait objects implement that trait.

trait Foo {
    fn method(&self);
}

fn something(obj: &Foo) {
    // want it to be true that the type Foo : Foo   
    something_generic(obj);
    
    Foo::method(obj); // virtual dispatch 
}

fn something_generic<Sized? T:Foo>(obj: &T) { ... }

• nmatsakis: surprising this doesn't work. cleans up formal reasoning: ufcs form corresponding to virtual dispatch, Trait::method(...) should work via virtual dispatch. In the compiler there's wierd logic to deal with this.
• nmatsakis: important for the alpha because we want Fn::call to work for boxed closures.

trait Foo : Sized // <--  implicit
{
}

trait Foo for ?Sized { }  

trait Bar : Foo { }

• nmatsakis: problem: there's an implicit constraint that 'Self' must be sized, mostly for consistency because all traits are sized by default. problem is that 'trait foo for ?Sized' ...[ what?]
• nmatsakis: want to make traits for unsized types by default, declaring explicitly when traits are only for Sized types.
• nmatsakis: removes some wierd corners of the syntax like for Sized?
• nmatsakis: seems to have minimal fallout because most traits actually don't care about sizedness. could be some bugs in the compiler that create more fallout.

trait Something {
    fn method(x: Option<Self>); // you might expect an error here
}

enum Option<T> { ... } // T : Sized default

impl Something for [int] {
    fn method(x: Option<[int]>) {...}
}

stability attribute changes

rust-lang/rfcs#507

• brson: There's been some negative feedback on this RFC, want to go through the arguments and see where we stand.
• nrc: Summary?
• brson: The basic revision here is to tie stability attributes to feature gates, where each attribute connects to a feature name. That means it's "just for us" (in std), not for external libs.
• brson: One pushback was that using this scheme to infer version requirements was pie-in-the-sky. We already know there are holes, it's not perfect.
• brson: But that wouldn't really invalidate the design; there are other motivations. It provides a way to track everything that goes into the language by tying them to a feature name. It makes the pipeline process of adding things to Rust more clear.
• brson: The second complaint was about taking away deprecated/unstable from userland
• brson: acrichto argued that the design of these features is not right for regular uses, because you have to opt in to total stability -- you'd rather have a white list of things to use unstably. He wants to punt on this for now, adding back a userland version of the feature later when the design is more clear.
• brson: I somewhat agree that automatic feature detection might be fanciful. But otherwise, I still think we should move forward.
• brson: We might change this RFC so that we can use less desirable names, leaving "unstable" etc for users down the road [ some discussion missed ]
• brson: should i forcefully deprecate these attributes or just make them meaningless?
• aturon: meaningless
• nrc: seems like useful info to keep around