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

Latest commit

 

History

History
288 lines (230 loc) · 19.7 KB

2014-08-26.md

File metadata and controls

288 lines (230 loc) · 19.7 KB

Agenda 8/26/2014

Attending

spernsteiner, acrichto, nrc, steveklabnik, aturon, larsberg, zwarich, brson, luqman, pcwalton, huon, azita

Status

  • brson: windows bots, windows bugs, admin
  • nrc: doing a happy dance because DST landed
  • nmatsakis: rebasing galore
  • aturon: RFCs new and old; collections; DST library effects; stabilization
  • acrichto: cargo registry, librustuv
  • pcwalton: non lexical borrows

Action Items

Core team decisions

  • niko: Aaron is joining the core team. In the time he's been with us he's been involved in fundamental design decisions.
  • brson: welcome, aturon!

if let PR 160

rust-lang/rfcs#160

  • acrichto: There was some discussion about while let as well. Might be something to consider, if we do merge this?
  • brson: I don't like the sound of that. Does swift have it?
  • luqman: Yes.
  • nmatsakis: Lets you write iterators cutely, I guess. I feel like this seems like harmless syntactic sugar. RFC phrased the semantics as a rewrite, which I'm not sure we want, but we probably would impl it with AST manipulation.
  • brson: Rewriting may have some unexpected interactions with exhaustiveness checking. Some of the examples had problems like that.
  • nmatsakis: Case is where chained ifs are mapped into underscores with conditions on them. Also, there are special rules on conditionals in match statements, due to soundness. So the official rewrite... any reason not to rewrite as a match with an _ and then whatever comes after the if? Anyway, I think I'm basically happy.
  • brson: The rewrite rules require a catchall case, which could be unreachable.
  • acrichto: If you have an if else and then an if else with temporaries in the first condition, are they alive in the second one?
  • nmatsakis: I think they are but they're not in scope...
  • acrichto: So, if I have a condition that does a mutable borrow, if we did a rewrite with everything in the catchall, the mutable borrow would be in scope, but I'm not sure it would in if/else.
// is this valid?
if let pat1 = (&mut foo).bar() {
} else if let pat2 = (&mut foo).baz() {
}

// this probably isn't valid
match (&mut foo).bar() {
    ...
    _ => {
        match (&mut foo).baz() {
            ....
        }
    }
}

struct Foo;
if let Foo = bar {

} else {
    // compile error
}

// translated to this match which is a compile error
match bar {
    Foo => {}
    _ => {}
}
  • acrichto: Seems like the rewrite would not be valid because the & muts would not be in scope at the same time.
  • nmasakis: Compilation error until non-lexical borrows happen. But you'd prefer it didn't?
  • acrichto: Yes. brson, you also mentioned that in this case we're worried about that being a compiler error?
  • brson: Yes.
  • nmatsakis: Right now, it's a lint about unreachable block.
  • acrichto: Compile error.
  • pnkfelix: Just include a tautological if guard on the rewrite?
  • acrichto: But then you can't bind by move.
  • pnkfelix: I thought zwarich was going to change that.
  • zwarich: Waiting for move after drop to land before implementing it.
  • brson: If guards anywhere force you to not be able to bind by move?
  • zwarich: Just in the one arm.
  • nmatsakis: The rewrite rules translate if let into a match. The entire if/else chain comes in as a sequence of match arms.
  • brson: He's proposing a single match with two arms?
  • nmatsakis: Yes.
  • brson: I keep not seeing that because the final example has a completely different rewrite rule.
  • nmatsakis: I wouldn't want to add special type rules for this construct, so I don't want to solve acrichto's problem unless we're solving it for match in a more general way. The bottom line is that not everything people want to do will work. But this is always true.
  • brson: Also concerned that this is a feature that seems harmless but we may regret it later. This has happened before.
  • pcwalton: feature gate?
  • nrc: Probably should. with/else was also proposed and withdrawn. There's also Simon's matches!, which is complementary but doing similar things. There's a lot of motivation for this feature area.
  • pcwalton: Yes, it's come up a lot.
  • nmatsakis: Why feature gate? So we can pull it later?
  • pcwalton: It might have effects on the rest of the compiler and force us into keeping them because backcompat. We have had this problem before with other features like the for loop de-de-sugaring and unboxed closures. For loops can't be feature-gated, and unboxed closures are also critical for 1.0. But since if let is droppable, I feel it's prudent to feature gate it. If the desugaring gives bad error messages or we find a problem with it, where it's unsound or doesn't have the right semantics, then we have to rip out the sugaring, put it in the compiler, and have a bunch of backcompat lang issues for everything we don't preserve.
  • nmatsakis; Seems fine. All new features will probably land under a feature gate.
  • zwarich: Is the hope that this could ship ungated with 1.0 and this is just an escape hatch? Or would this be a nightly release only feature? It will be very tempting, but if it's gated then it's not in the release and you have to use the nightly.
  • pcwalton: I'd hope we can ship it ungated. But if we don't feature gate it, we won't have the option of pulling it out.
  • nmataskis: I would not accept it if it was not implemented via rewrites. But any problems it will have are problems you could have writing a match statement today.
  • brson: If we do this, are we also committing to while let, since they come as a pair?
  • pnkfelix: That extension is not part of the RFC, right? I dislike taking things that are in the RFC's comments and considering them as part of the RFC itself.
  • acrichto: Agreed; there would be another RFC.
  • nmatsakis: OK, let's pull it in under a feature gate and see how it goes.
  • acrichto: I'll merge it.
  • brson: Do

associated items

rust-lang/rfcs#195

  • aturon: I put a handful of RFC we talked about at the workweek forward to try and merge. Associated items is uncontroversial now; hammered it out during the workweek. A couple of minor details need to be updated, which I would like to do before it lands. Can we land it this week?
  • brson: +1
  • nmatsakis: Yes.
  • brson: aturon, ping somebody to merge it when you're ready

ownership conventions

rust-lang/rfcs#199

  • aturon: Didn't cover at the workweek. This is trying to line up conventions on things like marking mutable variants of methods, byref vs. byval variants, etc. I'd be happy to speak to the details if you're curious, but the only part we're unsure on is if you want to mark something as move, e.g., with iterators (iter, mut_iter, and move_iter), in this RFC it becomes a suffix. But what do you say about transferring ownership? We've been moving away from moved to owned terminology. I've proposed changing to owned, but people don't like it and prefer moved or val. We have lots of different words for this today, which I think is what's making this hard.
  • nmatsakis: One problem with the word move is that sometimes the type implements Copy and thus it doesn't actually. How often do you think this would come up? Doesn't for vectors because in the case of iter it's not a problem. Maybe Option implements iter_move, even though it doesn't.
  • aturon: Doesn't come up very often. Most of the time we move by default; this is only when you're marking the other way around. When it does, it's on containers, so if you do have Copy data inside, you'll run into this.
  • acrichto: Same argument for owned, though? Int is still not owned.
  • nmatsakis: Depends on your point of view... I tend to think an Option is owned, and tend to think you're moving a Copy!
  • acricho: I find vec.iter_val() confusing because it doesn't invoke ideas of ownership or transfer.
  • zwarich: Two things I find annoying about val is if you have an associative container with iteR_keys and iteR_val you have a weird meaning. Also, if you have a clone of something, are you getting a clone of something or moving it? For POD data, it's the same as a move...
  • jack: I switch my vote from val to owned because I hate when move doesn't move.
  • zwarich: Move is just a copy where you can't use the original anymore!
  • aturon: I proposed owned specifically because we've been emphasizing the ownership terminology. Ownership used to be tied to boxes in some weird way in people's heads, which I think is getting in the way of this. We don't have to do it today, but I would like to get this RFC closed.
  • nmatsakis: Leaning towards iter_move at the moment. There's no perfect word. iter_owned doesn't... it feels wrong.
  • aturon: I can throw in a wrench! I'm trying to come up with a general convention, but for the special case of iterators, we could also use into_iter for this and avoid the whole question!
  • nmatsakis: I like that.
  • aturon: And we still have to resolve this question at some point. With multiple overlapping conventions (conversion vs. ownership), it's hard to know which convention to use. But I prefer ownership in this case.
  • nmatsakis: Any other examples?
  • aturon: None in the standard library. I'm sure there will be more.
  • nmatsakis: Because we always make ownership transfer the default?
  • aturon: We do have some move e.g. push_all_move
  • pnkfelix: I suppose nobody proposed iter_ref for the default?
  • nmatsakis: I've thought about it, but we call iter a lot. And we don't call iter_move or move_iter or whatever that much. push_all_owned also doesn't sound right to me. push_all_move isn't great, but it doesn't seem...
  • aturon: moved also resonates with C++ developers.
  • nmatsakis: Not incompatible with ownership.
  • nrc: I agree that it's about ownership when you're talking about moving. You're just moving ownership. Everything is owned; the action is moving.
  • pnkfelix: Unless you're copying.
  • nrc: It's imperfect, but so are all proposals. move seems least worst.
  • nmatsakis: I think we should call it.
  • aturon: I'm persuaded by move.
  • brson: you will ping somebody and merge

Servo update

  • larsberg: only problem is llvm assertion during upgrade. have a workaround by turning off debuginfo. mw says we might update to a new llvm version. not having backtraces is bad.
  • brson: you've been talking to mw?
  • larsberg: yes
  • brson: he thinks it can't be solved without an upgrade?
  • larsberg: last comment from mw:

rust-lang/rust#16483 (comment)

  • acrichto: sounds like we're just praying it fixes
  • acrichto: I'll try an upgrade

Privacy RFC

rust-lang/rfcs#200

  • nmatsakis: Last time we accepted a privacy RFC and I unfortunately missed a very important paragraph. I wanted to propose an amendment to it. The difference is that the RFC's goal was to prevent private things from leaking into public APIs. The current definition is based on a search of pub uses to see how far up the hierarchy the name leaks. I'm proposing we change this to just say if the thing is declared public then it is. Some of the goals of the RFC are not achieved in that you can't explicitly write the names of some types if there are not enough pub use paths to fully expose it, but you can have a:
mod outer {
    mod inner {
        pub struct Foo;
    }
    pub fn something() -> inner::Foo;
}

outer::something() // return type is public, but I can't name it
  • nmatsakis: Kind of bad, but I feel like the advantage is that if something is declared private you know it's only locally accessible vs. if it's declared public you know it is accessible. The other rules are hard to reason about.
  • pcwalton: Yes, when you get one of these errors, it's hard to understand why and how to solve them.
  • nmatsakis: That's part of my amendment. I should also update the motivation of the RFC to be about unsafe code insetad.
  • aturon: I think it gives a simple meaning to public and private, which is great. +1
  • brson: +1
  • pcwalton: Agreed; that was my original objection to the first one.
  • brson: Submit a PR?
  • nmatsakis: Just have to get it landed. I'll add the motivation to my PR and ping somebody.

Error interoperation

rust-lang/rfcs#201

  • aturon: Two error RFCs. One is the syntactic; skipping for now. The other is the try macro and Error trait. There are some suggestions for additional features, but I'd like to go ahead and land it. It's two things: a trait defining what an Error is and another trait called ??ERror that lets you use try! to convert between them. It's ready to merge.
  • acrichto: Let's do it.
  • brson: What are the last comments?
  • aturon: Right, small updates to the RFC. I'll ping someone once I make them.

Slice syntax

rust-lang/rfcs#198

  • aturon: Don't need to land today. This is an extension to the overloaded indexing notation to do all the slice indexing operations. Basically, two questions here that I'd like some feedback on. Inclusive vs. exclusive branches. If you use .. in pattern matching, it's inclusive, but for slices would be exclusive. Could be confusing because they don't match, but do feel like the right defaults. Consensus around the RFC is to use the same syntax and they just do different things in the two spots. Are people comfortable with that?
  • nmatsakis: Fine with it.
  • pcwalton: Torn between that and using ... somewhere. Whatever Ruby does (I know swift does the other).
  • nmatsakis: Arguably Ruby does it wrong. More dots = fewer items.
  • pcwalton: Weird.
  • steve: people only use two dots.
  • pcwalton: Ups of .. everywhere is less syntax and make neither Ruby nor Swift people angry. Downside is inconsistent. I am torn.
  • brson: If we were to use both of them, would we then have pressure to support both style in both positions?
  • pcwalton: We'd get asked, but I have a feeling nobody will ever use anything but a half-open range in expressions and inclusive range in patterns.
  • acrichto: If we have different syntaxes, it's impossible to mess them up since you can't use them in the other context. The failure mode is not that bad, whereas the failure for using the wrong ones is pretty bad.
  • pcwalton: Actually, I wouldn't put money on people not using exclusive ranges, because of the C pattern, where you say last_whatever=5 in an enum and people want to write 0...last_whatever. So, there's case-like statements translated from FFI error codes where you'd want it. I'm also biased because I like ... more than .., so I'd like to have it in the language somewhere.
  • nmatsakis: If we have two different syntaxes, we should phase them in to help people shift to the new semantics.
  • acrichto: Uncomfortable supporting both. I like having orthogonal syntaxes. Once you can mix them, it gets a little... I want only one, if we allow both in the same context.
  • brson: Prevents us from making the mistake in the future.
  • pcwalton: I'm not worried about having room to make mistakes in the future.
  • nmatsakis: Pattern matching on ranges is a pretty small deal, so changing it wouldn't be terrible. Maybe we should just change the ranges to ... and call it a day.
  • aturon: I'll update the RFC, get another week of feedback, and be back.

Tuple indexing

rust-lang/rfcs#184

  • nrc: Was on last triage meeting, move here. Being able to do t.N to get the Nth item out.
  • brson: Good, but adds a terrible rewrite rule to the parser to deal with floats vs. tuple access.
  • acrichto: I'd recommend taking out the rewrite rule and forcing parents around the access rules.
  • nmatsakis: Yeah, if you have .0.1.2, it might be time to have field names.
  • acrichto: Worried that if you have a 1/2 field tuple or struct, it's great, but if it's above that you should stop using the syntax.
  • pcwalton: Yeah, that's why it was removed from the language. Well, more complicated than that, but boring. I'm fine with having a minimal amount of support possible. I'm neutral on this RFC.
  • pnkfelix: Also neutral.
  • pcwalton: Don't need to add a bunch of tuple features to encourage their use.
  • nmatsakis: Yeah, I wouldn't want to put any effort into the implementation of this. Depends on how invasive the changes are. Borrowchk already thinks about it this way. One thing in favor is that borrowchk sometimes reports tuple error messages as a #, which is totally random, this at least gives us a syntax for that.
  • acrichto: Does remove the stdtuple module, which would be nice.
  • nmatsakis: If somebody did this, we wouldn't mind having it. Should land under a feature gate...
  • pcwalton: Yes.
  • brson: OK, so we'll say yes?
  • nrc: I agree, but I wouldn't want to spend time implementing it.
  • nmatsakis: Same.
  • brson: I'll propose the changes (remove the surface syntax and add a feature gate).

Memory exploit mitigation

rust-lang/rfcs#145

  • nrc: Adds compiler flags and attributes that are analogous to optimization levels, but with hardening memory w/ stack canaries, ASLR, etc. Not a lot of feedback.
  • pcwalton: Should not be an RFC. Feels like this is a request for a new compiler switch, which doesn't feel like a lang. design thing. There's a question as to whether there are levels to this.
  • brson: I agree, as long as this isn't an attribute. Once you touch the source code, it's not good. The source and commandline are different because source wants features and command wants levels.
  • pcwalton: Hrm. Doesn't seem appropriate.
  • nrc: Attribute motivation is if you want to turn on level 2 hardening but turn off the stack canary for a particular function, then you should be able to.
  • pcwalton: Also seems analogous to an optimization. But the right place to do that is a compiler switch. Stack canary feels like -fomit-frame-pointer, and that doesn't feel like a crate attribute.
  • nrc: But we don't allow that as a function attribute do we?
  • pcwalton: No. We could enable them as function attributes. But I don't see a pressing need to do so.
  • brson: Seems like a simple starting point would be commandline flags and then go from there.
  • pcwalton: Yes, it seems premature to design this when we really don't have experience with these features. It seems like linux distros turn them all on and some platforms like ios turn them all of...
  • brson: Let's tell kmc to add them within the framework of the codegen (adds?) features, not this other stuff. I'll do it.

Change syntax for extern

  • nrc: Take away the quote part so it looks more like an identifier instead of a string. Do you want extern ABI or extern{ABI}, etc.
  • brson: We do this as a string for reason.
  • nmatsakis: It's what C++ did. We used to have a more complicated notion of ABI that we've purged at this point.
  • brson: ABIs are arbitrary and not a fixed set...

(out of time)