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 (182 loc) · 18.6 KB

2014-07-01.md

File metadata and controls

206 lines (182 loc) · 18.6 KB

Agenda 7/01/2014

Attending

cmr, Luqman, jbailey, jclements, brson, zwarich, acrichto, pcwalton, bjz, aturon, nrc, steveklabnik, stuart, huon, dherman, pnkfelix, azita

Status

  • nrc: DST traits
  • acrichto: #[crate_id], cargo website, cargo build -j
  • brson: ToStr, windows toolchain
  • pnkfelix: non-zeroing drop
  • pcwalton: burning down P-backcompat-lang
  • aturon: conventions, stability dashboard, concurrency infrastructure

Action Items

New Intern

  • brson: Stuart Pernsteiner is joining us this week from University of Washington, and he'll be working with Nick.

Prelude

  • cmr: have a pr open for "range_inclusive". what to do about names in prelude in general? should we not be strict about allocating names in the prelude, esp. for non-traits?
  • brson: we should have guidelines, and be firm about it.
  • acrichto: rfc-worthy? seems minor
  • brson: important
  • cmr: not sure we need rfc, or just apply rules
  • brson: it would be nice to have a rationale
  • bjz: what functions are currently exported in the prelude?
  • acrichto: spawn ,range, etc... mostly traits, some for primitive... clone() is in the prelude
  • brson: policy discussion, or make a decision on this one?
  • cmr: put off the policy discussion
  • zwarich: no on the pull request, I very rarely need range_inclusive, why should I steal that name forever... range is common due to 0-based indexing, not range_inclusive
  • klabnik: need overwhelming rationale
  • brson: namespacing may seal this off forever. this may not be a valid thing to do for much longer. we only want to put truly pervasive things in there
  • brson: feel good: we've made a decision
  • dherman: aaron should probably spell out this decision in the guide
  • aturon: this is a very special case for rust libstd, not for general rust libraries
  • dherman: true
  • aturon: but we do need to think about it.
  • dherman: the prelude is an admission that the theory of modular programming breaks down for - the most common cases, but there should be only a few of them.
  • dherman: batteries included does not justify putting it in the prelude. should only be the things that every programs need.
  • brson: follow up?
  • cmr: yep.

0.11

  • acrichto: Release coming up in theory. Brian, you said there were some changes that broke piston? Not sure if it should block the release, it seems the release was cut before the breakage.
  • brson: I don't think we should break piston lightly with our releases, given that it's such a high profile project. But it looks like we'll be able to find a workaround in piston. I'm not too worried about it.
  • acrichto: I was thinking about releasing tomorrow. Is this on track for that?
  • brson: I'm ok with that. Our call for testing produced not a lot of returns, but that's how it usually goes. Any other concerns about the release?

String indexing (PR #15085)

  • brson: My PR to remove indexing from strings. We have a 1.0 issue saying we should do this, sitting around from before the RFC process. When the issue was filed the response was enthusiastic, but on the PR from commentors and even me who implemented it, the response is less than enthusiastic.
  • acrichto: Often we have issues that say we need to take action and we milestone them not always because we should do this but because we need to make a decision about them.
  • pcwalton: It returns u8 right? I don't see this as ... it's impossible to write string[0] == 'c', so I don't think it's dangerous.
  • brson: Right, we don't hide that strings are bytes.
  • aturon: That's my complaint. We expose the byteness in so much of the API surface that it's a bit weird to single out this particular convenience. Seems like it should be all-or-nothing.
  • pcwalton: ... ...
  • acrichto: Huon you originally opened the issue about this, what do you think?
  • huon: I still prefer to remove it, it's giving nice syntax to something which is bad practice. But if other people want to remove it I won't oppose.
  • nrc: To clarify, this is byte indexing?
  • steve: I'm a big ergonomics person, but even so it seems Rust emphasizes safety over ergonomics.
  • brson: In the past we've tried to use the type system to provide safety but this isn't really safety in terms of memory safety, but preventing bad things.
  • nrc: Do we really want the square bracket syntax? I can see the need for having the feature, but the square bracket syntax is a really fundamental operation. There ought to be a pretty high bar for having something so easy.
  • dherman: Do I understand that the worry is that it's not necessarily O(1)?
  • brson: No, it is O(1), but the concern is that it's working on bytes, and pulling bytes out of unicode strings is almost always wrong.
  • nrc: And I assume(?) that people will assume that indexing returns the last character but not the last byte.
  • zwarich: Looking at the diff, it doesn't seem that major. And most of the cases are things we don't want people to use, like casting the byte to a character or a character to a byte.
  • dherman: seems to me making strings indexable by byte is confusing layers of abstraction, but I don't have a strong feeling about this
  • brson: Sounds like we're fairly evenly divided, and fairly apathetic. Does that seem accurate?
  • pcwalton: Yeah, I don't really care.
  • felix: Has there been any pushback?
  • brson: Alex and Aaron have brought up the concerns here.
  • aturon: I'm comfortable with removing it -- it's the conservative thing to do, since we can add it back later if needed.
  • jclements: To clarify: the PR uncovered latent bugs?
  • zwarich, brson: No, just nastiness.
  • brson: cmr?
  • cmr: Yes, let's kill it with fire.
  • nrc: And the replacement is .get_bytes()?
  • brson: No, .as_bytes()[i]
  • felix: Since Brian said Alex and Aaron brought up concerns can you make sure they are in the meeting notes?
  • cmr: yes, please add in your exact reasoning if I missed it in the notes

Cross borrowing

  • pcwalton: Sorry for brining this up a third time. It's not used in many places, about a dozen, I'd like to remove it entirely. Someone in IRC today was confused by this very thing.

  • brson: Who made the case last time that we should not remove all cross borrowing?

  • nrc: I did, and I'm totally convinced now that we should remove it. [ general elation ]

  • pcwalton: The RFC here is PR 139.

  • brson: Is it already in?

  • acrichto: Proposed, not accepted.

  • brson: Unless there is argument, let's merge it.

  • cmr: A meta-point, can we wait a day or so before acting on decisions we make in the meetings?

  • brson: That's a good point, we probably should.

  • brson: I keep wanting to not get caught up in policy issues, but it seems like we don't need to broadcast these things too often since we post the meeting notes to e.g. reddit?

  • cmr: Yes.

  • brson: Ok, Alex, wait a day or so to merge it.

Two Possible RFCs

  • nrc: Some proposals. One is moving the lifetime name before the ampersand, ... are we interested in making RFCs for it?
  • pcwalton: I'm interested in it, but I don't think we should push forward on this before we have the lifetime elision stuff. I think we should do it after that.
  • dherman: A lot of this is affected by the visual affect, and a lot of that can be changed by the frequency of explicit lifetimes. It makes sense to wait the lifetime elision and see what the new world looks like.
  • nrc: Another is type ascription which seems to be something many people want but we thought would be a post-1.0 issue. Two things make me bring it forward. It would allow you to write lifetimes of expressions, ... which would be a backwards incompatible change. The other motivation is that the DST branch that I use is up for review right now, and it uses a lot more coercions. You often need to specify the type of something going into a coercion, and there are a lot of changes in that branch where I add an intermediate variable just for the type. Type ascription would help a lot there. I think it would be fairly minor to implement, so I'm curious if we still want to put it off to post-1.0.
  • pcwalton: I think we can do it. I don't want to add more things to the list, but ... I'm not sure anyone uses lifetimes on references in expressions anyway, it seems like something we should remove.
  • cmr: It doesn't even work today, does it?
  • felix: Right.
  • pcwalton: So we have a feature that the parser accepts and the typechecker ignores? [ yes ]
  • pcwalton: Well that's clearly a bug, let's remove it.
  • nrc: In that case, let's not do type ascription for 1.0.

Lifetime Elision

  • aturon: Wycats did a study and with some simple rules, we can remove 90% of explicit lifetime annotations. We can codify the common patterns. I submitted a pretty detailed RFC going through the changes and the statistics and the respone has been quite positive but people are concerned about one of the rules. I think we should accept it with both of the rules as they stand, and revise later if the last rule turns out to be ...
  • nrc: The numbers, it's 90% of all ..., do you know how the numbers match the rules? Is it like 85% / 5%, or [smaller fraction]
  • aturon: The contentious rule is that if you have multiple parameter, we propose to use the self parameter as the implicit lifetime. This doesn't come up often, but when it does, it is always the thing we do, maybe 99% of the time.
  • brson: Is there a design here that allows the simple rule that everyone agrees on but not the more controversial rule?
  • aturon: Yes, we can just say that you cannot elide the lifetimes if you take multiple lifetimes. Just need to leave off the last rule.
  • dherman: I feel like there is a strong justification that the third rule is the idiomatic way to treat self. It feels like when you're writing an OO data abstraction the self object is conceptually the owner of the stuff that you're working with. It's driving the data relationships. Is that the way you think of the rule?
  • aturon: That was certainly our intuition. It's clear that when you're writing methods, self is the special thing here, and it usually outlives the others.
  • dherman: ... I would hate to pick and chose based on raw numbers if we have a coherent set of rules.
  • pcwalton: I don't that's quite true. There's a strong theoretical justification for the first two rules but not the last. There are only two possible lifetimes in the first two cases: the lifetime of the reference you take (call it 'a) and 'static. And it's clear that you always want 'a. 'static is nothing but less information. There is only one obvious right thing to do in a theoretical and practical sense.
  • pcwalton: The third rule is different, than [... lots of noise ...]
  • pcwalton: What's happening in the compiler is that it's deciding that the self ... I'm saying that it's definitely quite a bit different than the other two.
  • aturon: Not trying to be super pedantic, but to push back on that, even the first rule is not the only possible way to fill in the elided parameters. If you have a function that takes two reference parameters, you might want them to share the same lifetime, and in that case you have to annotate.
  • steve: The controversy here is important, the reaction was "wait, self is special?". My understanding is that the controversy that self was treated more specially.
  • pcwalton: Right, and we don't treat them specially in the typechecker, only for method resolution.
  • felix: Question about the pushback, there's pushback for the first rule, but that's the current behavior. There may be other valid interpretations, but the only one consistent with what we do now is what's in the RFC?
  • aturon: .... for the first two rules, Patrick is saying there is only one way they could make sense. But I'm saying in the first rule there are two possible treatments, they all have the same lifetime or all have fresh lifetimes.
  • pcwalton: You're right, what I said was totally wrong, but it is true that we don't treat self specially in the typechecker. ... There is a conceptual reason the third rule is separate from the first two.
  • dherman: You're talking about theoretical justification coming from what are the possible solutions, but I'm coming from the perspective of allowing people to be precise when it matches the way we would idiomatically speak to each other, and that's a fuzzier thing when you're building on the crooked foundation of humans rather than the firm foundation of theory. And from that perspective, you need to look at real examples and check if the rules matches what I actually mean. Of course, Aaron has numbers but maybe it'd be better to look at actual examples and see if it [looks and feels right].
  • pcwalton: I trust Aaron's number, and I'm fine with these changes. I'm just saying there is a difference between the first two and the last rule, but I think we should take them all. We might want to go back on the third rule, but I don't see why we should.
  • aturon: One way to look at the third rule is: either leaving off the lifetimes is an error, or we provide a useful default. I suggest we start with the useful default, with room to revise later.
  • brson: Do you have any worry about what this self rule is going to like when we have real UFCS?
  • aturon: This is only affecting the way you break down the signature, the way the callee writes their signature, not anything with the caller.
  • brson: But it treats the self argument specially. In a UFCS world, self isn't special, it's just the first argument.
  • pcwalton: ... It's less special with UFCS, but it's still special.
  • acrichto: ...
  • brson: ... If the first argument type checks, that could be treated as a method in UFCS! Do you still want to require methods to be in impl blocks?
  • pcwalton: Yes.
  • aturon: As long as there is a clear distinction between definitions intended as methods, I think the rule makes sense. Some people have proposed using the first argument in general, but I'm uncomfortable with that.
  • brson: Ok, sounds like we're not worried about that, which is fine.
  • brson: So we've admitted that these rules don't cover every case. What is the error mode when the rules don't apply?
  • aturon: ... We have error messages that guide you towards writing the explicit lifetimes you want. In the case where the elided lifetimes are wrong, it's unlikely your function would even compile, and the existing messages are pretty good about guiding you toward the right lifetimes.
  • pcwalton: I think the compiler can always tell you what lifetime it should have, even if it doesn't today.
  • felix: Doesn't this interact with RFC 31, which extends the temporary rules to be based on lifetimes. Won't you see different (or at least unexpected) behavior based on infered lifetimes that have been elided?
  • aturon: Not quite sure, my RFC is only about function signatures.
  • felix: The lifetimes in the signature, to my understanding, will influence how long temporaries will live. e.g. certain RAII patterns may not act in the manner one expects. This was known and acknowledged in the discussion of RFC 31. But now we're moving towards a world where the lifetimes won't be as explicit, I'm not sure what the effects would be.
  • pcwalton: With the first two rules, I don't think it interacts much. The compiler does what you already meant to do. The third might have some impact on that but I'm not sure.
  • aturon: It's true that this makes the lifetimes more implicit, but one of the goals of the RFC is that the rules are very simple. if you see an elided lifetime you know immediately where the lifetime comes from. It's not inference, just shorthand.
  • nrc: Adding these elision rules is backwards compatible but removing them is not. I think there's an argument to not use the rules we're not sure about.
  • felix: We could feature gate rule three.
  • brson: Why not feature gate all rules?
  • felix: Rule three is the one we're not sure about.
  • brson: I think all additive features should be behind a feature gate, since that's going to be our mode of operation in production. ...
  • jclements: But part of the advantage is helping people who don't have much experience with Rust and certainly won't be using feature gates!
  • brson: It's to try to prove the feature before turning off the feature gate.
  • felix: I see the point John is making.
  • nrc: ... even if we add it and then remove it, it's not just our change, it's that others experimenting with rust also have their code broken. There's still a cost to removing features.
  • dherman: I think this is a really important 1.0 issue, since it changes how you think about lifetimes. We want Rust to be strongly adopted at 1.0, and I think a Rust with lifetime elision is very different than without. ... I think we'd be missing a big opportunity for 1.0, and that it would hurt adoption.
  • brson: It's not clear if you're proposing a gate.
  • dherman: ... Not putting them behind a feature gate won't cause existing code to break, it will just be more explicit.
  • brson: Yes, but it's not clear if you're opting into this feature.
  • pcwalton: I'm not worried about this issue.
  • brson: It's not whether we're worried about it, but whether we have the discipline to ... [ ... details ... ]
  • brson: I agree and disagree. I think that we need practice for working with 1.0.
  • acrichto: I agree with Brian, it's ... 1.0 is rapidly approaching, it's on the horizon, ... We can keep this behind a feature gate for two weeks and remove it.
  • pcwalton: But then you lose two weeks of testing.
  • acrichto: ... ...
  • brson: We have 4 minutes, can we reach a decision about the lifetime elision RFC.
  • aturon: I think everyone agrees with rules 1 and 2.
  • brson: Let's table this and come back to it.

RFC PR 148

  • nrc: Do we want to keep this open? It's the <> to [] changes.
  • acrichto: It's so new, I don't think we should close it.
  • nrc: Even so, if we're not going to do it, I don't think we should keep it open.