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

Latest commit

 

History

History
229 lines (191 loc) · 15.1 KB

2014-09-23.md

File metadata and controls

229 lines (191 loc) · 15.1 KB
Raw

Agenda 2014-09-23

Attending

aturon, pcwalton, brson, acrichto, nmatsakis, steveklabnik, fnkfelix, zwarich, larsberg, nrc, jack

Status

  • acrichto - cargo pkgids, cargo registry (heroku), cargo bugs
  • pnkfelix - landing xxx drop semantics PRs, investigating box sugar
  • pcwalton - P-backcompat-lang
  • nrc: bug fixes, RFCs, highfive, moving issues to RFCs repo
  • aturon - starting Runtime removal, conventions RFCs, numerics simplification
  • nmatsakis - multidispatch, builtin traits, lots of RFC reading

Action Items

Static vs dynamic drop

rust-lang/rfcs#210

  • pnkfelix: There's been an ongoing discussion about whether Rust/the community wants static drop semantics.
  • pnkfelix: One camp says: static drop semantics is wrong; we should keep dynamic drop semantics but improve the implementation.
  • pnkfelix: Another camp says: we need to go even further, and drop as eagerly as possible.
  • pnkfelix: I looked at this proposals, and I know others have as well. At this point, my inclination is to stick with dynamic drop semantics. I'm not sure I personally want to program that way, but I don't feel like I need to force my style on others.
  • pnkfelix: The main motivation for static drop semantics is efficiency. If we can get that with dynamic drops, all the better.
  • pnkfelix: In both the static and improved dynamic drop semantics, you identify control-flow merge points where there are different sets of drop obligations on the different paths, e.g.:
let x = box 3u;
if boolean() {
    drop(x);   // (or otherwise move `x`
} else {

} // this is a merge point with differing drop obligations
  • pnkfelix: In the static drop semantics, this would cause an early drop to be inserted on the else branch. OTOH, the dynamic drop semantics we have today will track whether x has been dropped via a flag, and drop it at the end of the scope.
  • pnkfelix: The heart of the static drop proposal is to identify merge points like the above. Since that's a statically-identifiable set, you can associate each such merge point with a flag, on the stack, that tracks whether the variable has been dropped.
  • pnkfelix: In the common case, you won't need such flags.
  • pnkfelix: But the crucial point is that this is static and finite. The trickiest part of doing this is just identifying the paths with varying drop obligations, which I've already done.
  • pnkfelix: So, we'll just have a set of drop flags inserted on the stack frame for a function, rather than storing them within the structures. It also allows us to get rid of zeroing. The only place that there's zeroing is when initializing the flags, but that should be effectively no cost.
  • pnkfelix: About eager drop: it would really make it harder to write certain RAII patterns. I was already worried about that with static drop, but eager drop makes the problem far worse. The person proposing eager drop proposes working around this by using explicit calls to drop to keep the variable alive -- and that's tantamount to bringing back manual memory management. Not so good.
  • nmatsakis: I think we'd want some "scope" keyword, or some other way to specify how long you want something to live. It's a lot of additional machinery, and not realistic on the 1.0 timeframe.
  • pnkfelix: I do think some people like the eager drop idea, but it's not clear that it fits well with Rust
  • acrichto: Will this generate flags on the stack unconditionally, or only when needed?
  • nmatsakis: We don't have to define this. It's an optimization question.
  • pnkfelix: There's compiler heroics you can do to identify when the merge points aren't needed. But we don't want to make any promises.
  • nmatsakis: My preference would be to start with naive trans and let LLVM optimize things away. We can add optimizations if we find them necessary.
  • brson: But people should be able to guarantee that no drop flags will be created?
  • pnkfelix: Yes, you can add drop calls yourself to any merge points. Could have rustc/a lint help with that.
  • nmatsakis: One question is whether we still want a lint that triggers when drop flags would be needed -- just as a warning. I wouldn't want it on by default.
  • brson: I'd like to have that to be sure those optimizations are being hit.
  • acrichto: We'd have the analysis already, so why not keep a lint around?
  • nmatsakis: You wouldn't have to go through the heroics to keep the message count down
  • pnkfelix: One question about the goal of the lint. Is it about oddities when the drop happens at all? Or about the optimizations?
  • nmatsakis: Yes, those are somewhat distinct.
  • pnkfelix: I ask because, if the lint differs from trans, that would be misleading in terms of the optimizations. But that's getting into the weeds. They'd probably share code anyway.
  • acrichto: So do you want to update the RFC or post a new one?
  • pnkfelix: I think withdraw and add a new one. It's a reversal of attitude.
  • brson: What about mismatched moves in branch arms? Part of the proposal was to restrict the binding types in multiple match arms. What was the decision there?
  • pnkfelix: That will be taken out; it's a non-issue, and the semantics of match won't change. (That was already removed from the static drop RFC).
  • brson: Sounds like we're all in agreement about the next step?

fail! -> panic!

rust-lang/rfcs#221

  • aturon: The name 'failure' makes it awkward to talk about other failure modes, e.g. returning Result: 'if the operation fails then ...'. Ambiguous word.
  • aturon: Proposal renames 'task failure' to 'task panic'. Discussed at work week. Feedback positive. General agreement that 'fail' is not a great name. Basically consensus on 'panic', no great alternatives.
  • pcwalton: +1
  • acrichto: Can we preserve fail! but deprecate it? Our deprecation warnings don't deal with macros.
  • aturon: Not sure. Worth looking at.
  • brson: Could put unstable function inside of fail! but prob won't trigger warning.
  • aturon: Easy change to make in code, so not too worried about it. Worse change is going to be upgrading docs.
  • steveklabnik: it's cool

int literal to float inference

rust-lang/rfcs#183

  • brson: Right now, when you have an int literal without a suffix, it will usually infer the correct one, and similarly for floats. But a lot of people would like int literals to also infer to floats. Also, with a range analysis to make sure you're not losing bits. That's what this RFC proposes.
  • pcwalton: The range analysis seems orthogonal
  • brson: The int -> float conversion raises new questions here
  • pcwalton: Already problems for int, though.
  • brson: The actual range analysis is an "Unresolved Question"
  • nmatsakis: It's not unique to floats, and we already have a lint that we should be able to apply.
  • pcwalton: I'm OK with it.
  • nmatsakis: I agree it's annoying to write 1.0
  • pcwalton: I like the explicitness, but I suppose others disagree.
  • brson: I worry about adding little features like this that are "mostly harmless"; I'd like to slow down on it.
  • pcwalton: It's backwards-compatible, so no rush.
  • nmatsakis: Currently, if you have a left-shift operator we require it be integral, which is distinct from floating points.
  • nmatsakis: We'd have to complicate our type checker a bit, but backwards-compat.
  • acrichto: Consider this example:
trait Foo {fn m(&self);}
impl Foo for int {..}
impl Foo for f64 {..}
fn foo<T: Foo>(t: T) {}
fn main() {
    foo(1); // would work
    1.m(); // would not work
}
  • acrichto: is this an error?
  • nmatsakis: Yes, it is today. Under the proposed integral fallback, it'd be allowed. But not for methods, where we have to know the type "in the moment", and we don't do the fallback at that point. In the other case, we can defer the decision and then apply fallbacks.
  • nmatsakis: I don't think that's a problem particular to floats; same thing with other int types. i.e., if you had impl Foo for i8 {..}
  • aturon: +0.5
  • nrc: I like it, but think we should postpone
  • pcwalton: Whenever I do graphics programming, I write the dot (in C/C++)
  • nmatsakis: what about: 3 / 2? The integral fallback seems more surprising there (the outcome will depend on the ultimate inferred type)
  • nmatsakis: Makes me mildly uncomfortable. You might have some trait defined over all numeric types:
compute_logarithm(5, 3/2) // --> compute_logarithm(5, 1)
fn compute_logarithm<T:Num,U:Num>(t: T, u: U) { .. }
  • nmatsakis: Again, it's already true with integral fallback, but less problematic.
  • aturon: Seems like everyone wants to postpone.
  • brson: Agreed.

Transferring RFC issues from rust repo to RFC repo

  • nrc: We've been discussing this on email, and I have a script ready to go. But doing this will generate a lot of email. The script I have copies over the comments as well. I don't see any way to stop github from sending emails, even temporarily.
  • nrc: We could warn people in advance. Or we could just not move the comments. But people won't go back and read them
  • nrc: Or we could create one big post with all the comments embedded. You'd still get a lot of email that way.
  • steveklabnik: I have tons of emails coming from github. I use gmail, so it'll all collapse into threads anyway.
  • pnkfelix: Will they have a common prefix so that we can distinguish them easily via a filter?
  • nrc: Doubtful; you'll just get standard github issues.
  • aturon: I don't think we really need the comments; just link to the old issue. Gives us a fresh start.
  • nrc: Anybody object? [no]
  • brson: A related issue. People have a hard time tracking postponed RFCs. Suggestion was to open an issue whenever we postpone, and link to the postponed RFC.
  • nrc: Do you want me to automatically create issues for the postponed RFCs?
  • brson: If it's easy, yes.
  • nrc: I'll look into it.

Update from Servo

servo/servo#2853

  • larsberg: No big Rust blockers. We have one small blocker -- an infinite recursion in rustdoc, which prevents us from generating documentation for [missed]. I don't see any owners for this issue, not a big deal.
  • larsberg: We've moved to Cargo, and there have been a few growing pains.
  • jack: Cargo 482, 483, 601
  • jack: we need 483 and 601 most urgently. Currently have to rebuild servo for each path dep
  • jack: The 601 bug is about custom profiles. When Josh is working on Spidermonkey, we need extra debugging info that we don't want even on a debug build. For example, skia debugging makes GL unusably slow. We need some way to set up profiles.
  • acrichto: Does Servo depends on Spidermonkey and Skia at the top level?
  • jack: No, it's a dep chain in this particular case
  • acrichto: We recently added cargo build --feature where you could specify in the manifest what the feature means
  • jack: That has to be transitively done? Seems like it'll work, but annoying to do it transitively.
  • acrichto: Possible to do better; let's talk offline
  • jack: The other issue is fixed with package ids, I think
  • acrichto: That covers half of it, there's more to do. I'll try to get to it this week.
  • brson: Should we assign someone to the rustdoc issue?
  • acrichto: I'll do it

cfg syntax (RFC 194)

rust-lang/rfcs#194

  • acrichto: This is a proposal to change the syntax of cfg attrs and macros, and add a new attribute.
  • acrichto: Right now, you can't conditionally apply an attribute. For example, we have an ignore attribute which takes a cfg, but involves a lot of custom coding. Reworking the syntax will help.
  • acrichto: The other motivation is that if you have #[cfg(a,b,c)] it means that all must match, while if you have multiple #cfg attrs it means any must match
  • acrichto: The proposal is to flatten to a single cfg attr, with explicit any all and not operations that make explicit what the logic is.
  • acrichto: Right now, you can't express cfg as a syntax extension. This RFC would let you do that.
  • acrichto: Eventually, you would not be able to write multiple cfg attributes, or ones with multiple clauses.
  • acrichto: The attribute being added is cfg_attr that takes a cfg and an attribute, and conditionally applies the attribute.
  • brson: Does the RFC talk about nested uses of cfg_attr?
  • acrichto: It doesn't talk about it. I suspect it would just recurse, but we could also make it an error.
  • brson: I'm generally in favor. It sounds saner than our current setup.
  • nmatsakis: Do you envision eventually re-enabling multiple cfgs on an item?
  • acrichto: The plan is to allow it, but then all would have to be satisfied
  • nmatsakis: Then I'm in favor
  • acrichto: A long time ago, we envisioned having operators like && in the syntax, but that's not part of the spec. You'd need token trees, while the proposed RFC fits within current grammar
  • nmatsakis: I'd prefer that notation, but don't want to take the time to do it now. Can add later
  • acrichto: sfackler has already implemented
  • acrchto: I will merge

Entry revisions

rust-lang/rfcs#247

  • aturon: last week accepted HashMap refactor RFC (using 'Entry's). This PR updates that RFC with lessons learned from the implementation. Examples: whether to take self by value, or (?). Seems to improve use cases but doesn't complicate the API's.
  • aturon: I will merge

Newtype

rust-lang/rfcs#186

  • nrc: want to postpone this
  • acrichto: should we reserve the keyword?
  • nikomatsakis: hate the keyword 'newtype'. we decided not to reserve keywords and tackle some other way, think we should stick with that.
  • nrc: don't have concrete proposals. if starting from scratch I'd call 'type' 'alias' and use 'type' for this.
  • pcwalton: I like 'type' for assoc. types.
  • nrc: I thought we were not reserving keywords just in case, but if we have specific cases maybe we want them.
  • pnkfelix: so for every postponed RFC we might reserve keywords?
  • niko: judgement call
  • nrc: alternatives?
  • pcwalton: 'typedef'
  • pnkfelix: not convinced generalized newtype deriving doesn't solve this, but don't want to discuss now
  • nrc: maybe we don't reserve keyword and figure it out