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

Latest commit

 

History

History
206 lines (166 loc) · 12.3 KB

2014-11-25.md

File metadata and controls

206 lines (166 loc) · 12.3 KB
Raw

Agenda 2014-11-25

Attending

acrichto, wycats, steveklabnik, zwarich, pcwalton, huon, pnkfelix, brson, aturon, dherman, nrc

Status

  • brson: combined installer
  • pnkfelix: drop impl's and lifetimes (8861)
  • acrichto: cargo bugs, crates.io bugs, c_str stabilization, sync rewrite
  • aturon: teardown of std::rt/task, dst-path implementation, stabilization/conventions
  • nrc Foo<A=Bar>

Action Items

Extension traits

rust-lang/rfcs#445

  • aturon: conventions for extension traits that show up occassionally. -Ext suffix, signals traits that are meant to extend other types. No feedback.
  • brson: are there a lot? provide examples?
  • aturon: lots. iterators. obj safety rules cause more of these
  • wycats: drawback is a big deal - having to import extension trait
  • aturon: obj safety forced this issue to some degree. this is just creating a convention
  • aturon: libs are starting to create their own prelude modules, expected to be globbed in. may add language support in future
  • wycats: maybe mention in rfc
  • aturon: one issue: prev created -Prelude convention. This new convention should probably deprecate that one.
  • brson: rfc say that?
  • aturon: needs to be updated
  • nrc: possible to have more than one extension trait? what then/
  • aturon; good q. not fully addressed by this rfc. not sure if we can create a general convention. for iterators extension traits vary by constraints on the type, e.g. OrdIterator. that one is specifically addressed by RFC. generalized where clauses would make this less common
  • aturon: broader point of individual libraries extending iterator don't have a convention for
  • pnkfelix: sufficient that they are in different modules
  • aturon: maybe with renaming import
  • wycats: annoying thing about traits
  • pnkfelix: this convention is only for blanket impls?
  • aturon: not necessarily. imagine concrete Foo. trait that extends it might be just for that type
  • nmatsakis: traits that you don't expect others to implement
  • aturon: or take as a bound. tried to make this clear

Shadowed lifetime params

rust-lang/rfcs#459

  • nmatsakis: TL;DR: this RFC does not allow shadowing of type or lifetime params. This is a common source of bugs. Universally positive feedback.
  • nmatsakis: Main alternative would be a lint, rather than a hard rule. But then we'd have to change the lint pass to happen before the typechecker (to avoid the strange errors you can get when shadowing).
  • nmatsakis: We could always make that move later.
  • nmatsakis: OTOH, we allow shadowing elsewhere so this is somewhat inconsistent.
impl<'a, T> Foo<'a> {
    fn foo<'a, T>(&'a self) { ... }
}
  • wycats: The only source of pain here is, the current way people do lifetimes is they start with 'a and go up -- probably an anti-pattern anyway
  • nmatsakis: Definitely. But people also get confused about where they have to declare lifetimes.
  • wycats: No objection. But pedagogically, maybe we should encourage using real names.
  • nmatsakis: Agreed.
  • steveklabnik: I've tried to do that, but gotten pushback. (But I do agree with this policy).
  • nrc: I'd prefer a lint over a hard error -- feels more like a lint, because you're just making things more readable. You should be able to opt out of that. Scoping and shadowing are the expected behavior everywhere else, but seems inconsistent to forbid it here.
  • wycats: I feel like, if you were going to opt out, you should just change the name
  • pcwalton: What about macros?
  • nmatsakis: Hygiene.
  • acrichto: We also disallow shadowing on imports
  • nrc: But that feels different.
  • aturon: Can we just start with this for now, move to the lint over time?
  • nrc: Could be a lot of fallout. Not sure if you can automatically fix it.
  • pnkfelix: Would catch bugs. [cross-talk]
  • wycats: I don't see the value of the lint; any human who would want to opt out could just change the name. Code generators can deal.
  • aturon: So, this is coming up now because it's not back-compat?
  • nmatsakis: That, and for friendliness to newcomers at 1.0 [missed]
  • nmatsakis: There have been a few times where we want to do something as a lint, but can't do so early enough.
  • brson: Hard error seems like the conservative approach. Is there a migration path?
  • nmatsakis: We could warn.
  • brson: Even if we don't do it for a full cycle, the heads up will help.
  • wycats: Agreed
  • nmatsakis: So, we take this with a hard warning for now, and amend later? That will largely solve the usability problems
  • wycats: We could decide to do a lint based on compelling use cases.

Servo issues

  • kmc: There's a bug with Send trait, #19318, looks like that's being worked on. Let us know if you need anything from us.

Unused type params

rust-lang/rfcs#447

  • nmatsakis: This issue is a bit tricky. The gist is that we should not allow type params on impls (and maybe fns) that don't get used in the "first line". E.g.:
impl<A> Foo for int {
    fn get(&self) -> A { ... }
}
  • nmatsakis: We currently accept things like the above; often this will fail to typecheck because there won't be enough constraints on the type variable. This comes up today when what you really want is associated types:
impl<S,H:Hasher<S>> Hash for Foo<H> { ... }
  • nmatsakis: I'm worried about this because, going forward, the semantics are a bit unclear wrt multidispatch. We'll often successfully infer within a single crate, but when you add more impls, things may start to fail -- it's brittle. E.g.:
impl Hasher<MyState> for MyHasher { ... }
// we might be able to infer that S=MyState if H=MyHasher

in some other crate:
impl Hasher<MyOtherState> for MyHasher { ... }
  • nmatsakis: I think the semantics are a bit ill-defined if you allow these kinds of impls. There's no way for users to say what the value of these type params is, and that impl can often be required through several levels of trait matching. If we ever want to allow for specialization, this might be an issue, because we have to make decisions later.
  • nmatsakis: Unfortunately, before associated types, I'm not sure these can be fully removed, e.g. consider the Hasher example. I'm not sure what the best course of action is.
  • nmatsakis: In all the cases I've seen, you could move the parameter to the method, or to be carried by the type.
impl<F> SomeTrait for Bar { ... }
impl<F> SomeTrait for Bar<F> { ... }
  • nmatsakis: I'm worried and think we should try to fix it, but I don't think we can act on it today.
  • brson: Are we confident that we should merge it now?
  • nmatsakis: I'm confident that we need to deal with the issue, and this RFC is my preferred way. But it hinges on the fate of associated types.
  • brson: Are there alternatives?
  • nmatsakis: A couple. You'd have to change coherence around multidispatch. You'd want to say that you can't add new impls of the kind I was showing above. That would not be great. [ some discussion about the status of associated types ]
  • wycats: let's double down on associated types
  • nmatsakis: yes, let's
  • nrc: I'm happy with the RFC.

es6-style string escaping

rust-lang/rfcs#446

  • pcwalton: Instead of \u followed by four hex digits, you use \u { .. }, which accounts for Unicode getting bigger. This seems very reasonable to me. Can even do it backcompat.
  • brson: Could deprecate for a couple beta cycles.
  • pcwalton: Yep, don't even mind keeping around the old syntax forever.
  • brson: This makes us less compatible with some langauges, but makes us more compatible with es6
  • pcwalton: It's forwards thinking; Unicode is not 16 bit any more.
  • wycats: I think other langs do this, e.g. Ruby
  • pcwalton: Right, we should avoid inheriting the legacy cruft here.
  • brson: We only did our current approach due to Python's precedent? Or was there some other reason?
  • nmatsakis: Don't think so.

tuple indexing/if let

  • brson: Last week, we looked at this, but I think it was blocked on some research by nmatsakis?
  • nmatsakis: I'm fine letting this go through right now.
  • brson: low priority. we can punt another week

int fallback

rust-lang/rfcs#452

  • nrc: I sent mail asking for objections. brson said he wanted data, which I think is important. I think we have to implement the fallback and experiment; we've already merged the RFC so I think that's OK.
  • nrc: acrichto had some objections about the practicalities of the change; I'm still pondering the questions there.
  • nrc: There are a bunch of questions around int fallbacks. The only one I feel strongly about is falling back to i32 rather than int. But that would mean the soft convention (for random examples, or talking about size of the mantissa of float) -- should those default to i32? And also the renaming issue. Consensus on the latter seems to be iptr and uptr.
  • wycats: I feel like the status quo is hostile to pedagogy.
  • nmatsakis: Which part?
  • wycats: The lack of fallback
  • nrc: Reintroducing fallback was already approved. The only question is what to fallback to, or whether to rename.
  • pcwalton: Strong community consensus around i32, because it's faster
  • nrc: It seems that i32 is the "right" thing to do, but we've determined that it doesn't make any practical difference.
  • nmatsakis: Why is it the "right" thing to do? Though, fwiw, I think we could just fallback to i32 for unconstrained types and change nothing else.
  • acrichto: I have reservations about that.
  • wycats: When does this become observable?
  • nrc: Overflow.
  • wycats: But we're talking about people writing literals. Seems far-fetched that it would matter.
  • acrichto: One concrete program that's faster is, e.g., fib
  • nmatsakis: But to write that program you have to write a type name
  • huon: There's also vectorization
  • zwarich: But presumably you've then written a type somewhere. There is the question why uint is pointer sized. My experience is that you do not want pointer-sized ints by default for systems code, but I think that ship has already sailed.
  • wycats: Normally I would say go for safe over fast, but here both are safe.
  • brson: There's also the naming issue, which is tied up with the fallback
  • nmatsakis: Does it have to?
  • nrc: I think so
  • nmatsakis: I think if we want to tie these together, we need data. I also think we should write out our reasoning here.
  • pnkfelix: Which data specifically?
  • nmatsakis: My gut feeling is still that working with ints in Rust is nice and in C is confusing (because of sizes); I want to know what % of things turn out to be int sized anyway (i.e. what % are used for indexing into memory vs for numeric computations).
  • steveklabnik: When is fallback coming back?
  • nmatsakis: Just waiting for time to implement
  • nrc: It's backwards compatible
  • steveklabnik: I care because of the amount of docs I'm writing which use '5i', which will still compile post-fallback but we'll want to update to remove to keep in line with convention rust-lang/rust#15526
  • nrc: One reason i haven't just done this is that the RFC wanted to make it work with inference. But we could just revivie the old fallback (should be easy) and deal with inference later on
  • nmatsakis: I don't want to be left in an "odd" state where we prefer the int fallback over other kinds -- like the default type param fallback.

Macro update

  • kmc: I haven't updated the RFC yet, but I've been working to incorporate our earlier discussion. If we're going with the model of putting an attribute on extern crate items, I think we should do the same for mod items. [some lost] You should write it by the module you're actually changing, rather than at the top of the module (?) Lots more to discuss soon.