meeting-2016-01-27.md

Agenda 2016-01-27

• rust-lang/prev.rust-lang.org#289
• specialization extravaganza (aturon)
• copyright dates (brson)
  • rust-lang/rust#31007
• rename UFCS? (steve) UFCS = "fully qualified path" (and RAII?)

Web site translations

• Increasing community interest in offering translations of e.g. the web site
• Want to have a clear, proactive, offiicial process here
• Outcome of discussion: https://internals.rust-lang.org/t/translations-for-rust/3126?u=aturon

Copyright dates

• See rust-lang/rust#31007

Naming UFCS

Best candidate so far: "qualified path"

• <T as Trait>::method - fully qualified
• T::method(val, ..) - type qualified
• Trait::method(val, ..) - trait qualified

Also applies to projections:

• <T as Trait>::Type
• T::Type
• Trait::Type <-- this doesn't make any sense :)

Specialization: dealing with lifetimes

Specialization cannot rely on lifetime information (due to trans limitations, undesirability of tying dispatch to region inference):

trait Foo {
    fn foo(&self);
}

impl<T> Foo for T {
    default fn foo(&self) { println!("hi"); }
}

impl<T: 'static> Foo for T {
    fn foo(&self) { println!("static"); }
}

fn bar<T>(bar: &T) {
    Foo::foo(bar) // you might expect this to print "hi" or "static" depending on whether T: 'static
}

Options:

• "Principled approach": somehow make this situation an error outright

#[lifetime_dependent]
trait Foo { .. }

// this is ok because of the attribute
impl Foo for &'static str { ... }

trait Bar { .. }

impl<'a> Bar for (&'a u8, &'a u8) { ... }

impl<T> Bar for T {}
impl<T: Foo> Bar for T {} // you can't do this
impl<T: 'static> Bar for T {} // you can't do this

#[lifetime_dependent]
trait From<T>

impl<'a, E: Error + 'a> From<E> for Box<Error + 'a>

Problems: - complicated, no easy mental model; another knob in the trait system - sort of hard to predict which you will want - breaking change to add or remove the attribute - would rule out using From in specializaton, likely many others - Conclusion: this is basically a non-starter

• "Worse is better approach": allow these impls, but do something sensible if you ever exercise them

• We can potentially "ignore" impls that require knowledge of lifetimes for the purposes of specialization

• We could probably issue warnings when this happens

• Why warn and not error?

  • this can arise when combining two traits that you have no control over
  • if we make this a hard error, then you are just stuck and cannot combine those crates
  • if the spec is for purposes of performance, prob fine to fallback to slower path

• By warning of course we mean lint, maybe default to error

• In simple cases (intracrate) we can see the problem at declaration site

• But in extreme cases it would be when combining two crates

• To have a problem, would have to take types from one crate and feed them to another

• pushed thoughts on stack (nmatsakis)

  • if we expect people to use conversion traits in spec, they wouldn't necessarily be able to take advantage of Box<Error>?