- Servo hi-pri servo/servo#2853, need owner for rust-lang/rust#16366 (larsberg)
- RFC 192 -- type/object parameter bounds ( rust-lang/rfcs#192 ) (nmatsakis)
- RFCs http://discuss.rust-lang.org/t/next-weeks-older-rfcs-for-discussion/353
- syntax Q: why not
<oper w/ sig. spaces to avoid::<(pnkfelix)
pnkfelix, larsberg, jack, zwarich, brson, azita, spernsteiner, steveklabnik, pcwalton, aturon, Luqman, nrc, nmatsakis, dherman, huon
- brson: 1.0 lib issues, gcc, windows, seo
- aturon: moar RFCs
- nrc: dellocating DSTs
- pcwalton: P-backcompat-lang, incl. where clauses and associated types
- brson merge rust-lang/rfcs#192
- nrc take care of rust-lang/rfcs#101 (just do syntax change)
- pnkfelix grep codebase to eval
<change - brson merge rust-lang/rfcs#116
- huon close rust-lang/rfcs#129
- niko merge rust-lang/rfcs#136
- larsberg: felix knocking out the problem with the quoter.
- larsberg: new bug #16366. rustc is putting drops in weird places. we are working around it.
- nmatsakis: looks like a legit 1.0 bug
- brson: since we've got a workaround should we just nominate it?
- felix: you identified this location ...?
- jack: this expressed itself as double-dynamic-borrow error because it was interpreting random memory as a RefCell.
- nmatsakis: No RefCell in this code.
- jack: The JS isn't getting destroyed.
- nmatsakis: let's discuss offline.
- brson: since it's a workaround, we'll nominate for 1.0 and at least triage within two days
- nmatsakis: This RFC is an extension to the type system to allow us to capture references inside of objects, handle errors in a uniform way, etc. Also closes some bugs because the old way incorrectly enforced some rules. I'd like to accept this! How much detail would people like?
- pcwalton: This is already partially accepted; we discussed it in a 1.0-backcompat meeting. I suspect this is grandfathered in.
- nmatsakis: There's also a pending PR.
- pcwalton: Closes a 1.0 P-backcompat-lang. issue, in fact. It also fixes some major memory safety problems.
- nmatsakis: No negative comments; everything has been positive so far.
- pcwalton: Also don't know how to do unboxed closures without this.
- zwarich: Are the bounds commutative? Can you reorder as much as possible around the +?
- nmatsakis: No significant order.
- zwarich: That wasn't true for trait bounds...
- nmatsakis: Has always been the case. Except in an object type the main trait must go first, though I'm planning an rfc around "main" traits. soon. Only thing that might be surprising is an object type can only have one region bound and it must be the most general. Reason is otherwise inference is very very hard and there's no real use case for it. There's always a better bound to give. You can't say "I have a lifetime that outlives 'a and 'b", though you can give orderings such as "I outlive 'c which outlives 'b which outlives 'a". There's one minor fix from nrc concerning multiple bounds that I will fix.
- brson: Seems like there are no objects; let's do it. I will take an action item for it.
- pnkfelix: I'd like to require the LT and GT operators to have spaces around them. Also, I'd like to require that the type application has no spaces before them. The reason is that we can get rid of ::< syntax because there's no more ambiguity. We'd also have to deal with our current closure lifetime parameter (e.g., by adding the
forsyntax suggested by gabor). But is it anathema to consider this? - pcwalton: I would like to consider your idea because I really dislike the ::< thing. It's not as strange as it may seem. We got into this situation back when we did not have :: - we had . for module lookup and such. Originally, it was .< with this ambiguity, which graydon took from ES4 (nee ActionScript).
- dherman: In ES4, that idea ALSO came from graydon!
- pcwalton: When we changed to ::, it became ::<, which I brought up, but we wanted to keep consistent. It turns out that ::< is a problem and I've never liked the look of it. I've always assumed that introducing significant whitespace would be a hard sell. People may wonder why other languages that use < for generics and comparison don't suffer this, but they all dodge it. C++ knows during lexing when it's a type and fixes it that way. In Java, methods aren't first-class types, so a less than can never follow a type - it can only follow a method. None of this is relevant to Rust, unfortunately. So, I think pnkfelix's approach is worth considering.
- dherman: In Haskell, they do a similar trick for the . syntax. . with spaces is composition; without, it's struct field selection. It's a different syntactic space, but works well for them. The question is whether people like the these restrictions. It's just a question of whether people object to this style requirement forced by this rule. As a practical implication, it's worth thinking through what errors you will get when the spaces are wrong.
- pcwalton: This is also similar to the rule we have with binary operators and }. It shows up when you do
let x = if foo { bar } else { baz } - 1, which doesn't work. - nmatsakis: It does, but there are things that don't work...
fn foo() {
if cond { 0 } else { 1 } - x
}
- pcwalton: Right. Just pointing out we don't have a clean, pure grammar here. We do have some precedent for doing slightly dirty tricks.
- nmatsakis: Feels different than these other cases for me. Maybe comparable to identifier in scope resolution for patterns. It does feel a little random to say that LT requires spaces but the others don't.
- pnkfelix: I thought about going further and saying it applies to other operators, but that seemed extreme.
- pcwalton: I've seen people mix spaces with + and * to emphasize order. But also seen spaces for array indexing...
- zwarich: I've seen people omit spaces with < when doing a ternary operation, for languages with it.
- pcwalton: Fortunately, don't have it.
- nmatsakis: Three options. If it's eliminating the < ambiguity, we do have infinite lookahead in the parser. The brace solution doesn't eliminate the ambiguity. Or there's pnkfelix's. The advantage of pnkfelix's is that it's simpler for tooling (e.g., for emacs mode and matching).
- pnkfelix: I think it depends... including on whether the > requires spaces
- nmatsakis: There are people who prefer to put it on its own line - probably a non-starter.
- pnkfelix: In an expression context, do you want it in a parenthesized context?
- nmatsakis: Some people want to write the following pattern:
fn foo<
T,
U,
V,
>()
- nmatsakis: Have you grepped the codebase to try this out?
- pnkfelix: No, I wanted to get the history lesson before moving forward.
- pcwalton: There's no slam-dunk reason for the way it is today. Your proposal was never considered, as far as I recall.
- nmatsakis: You'll get rid of people complaining about ::<, but you may get some insane grammar complaints.
- pnkfelix: It's forward-compatible; we could always do infinite lookahead in Rust 7.0
- nrc: Plan was to go over the punted rfcs from the last month and unpunt them. List is the ones that are Discussed+PostponedForMoreFeedback. Any requests?
- nrc; Start with 101, allowing multiple fixed-sized subslices in pattern matching. Last time, we weren't enthusiastic, but there was another option, which was allowing ourselves to do it back-compat by changing the syntax to have
..after the things to match instead of the things before, IIRC. That would not change any semantics. From the RFC discussion, that seemed the more logical order anyway. The question is, unless there's a desire for multiple subslices, do we want to make this change in order to allow us to be backwards compat? - brson: Want to stop adding features to slices. Do we want a syntax change to it right now?
- nmatsakis: This would stop adding features because we're afraid of slices? Want to get them under control first/
- brson: The code that matches them is a mess.
- nmatsakis: Aha. Seems fine otherwise.
- brson: The feeling some people had is that slice patterns in general add corner cases on top of corner cases. People keep wanting more features from them. So, who wants to change the syntax?
- nmatsakis: No objection.
- pnkfelix: Fine with it.
- nrc: How about, are there any objects? Because there's no downside to changing the syntax.
- pnkfelix: The count in a fixed-length array - would that still come after it?
- nmatsakis: No, we're swapping that the name comes before. Not changing the syntax of fixed-length arrays in any way.
- brson: OK, pull together a new RFC that does that? This is an older RFC, so modifying this one might be hard. Anybody motivated to draw up the new one?
- nrc: I will do so. Can somebody close 101?
- steve: Should we let the 101 author see if they want to modify the RFC to the new one instead?
- nrc: Sure, I'll comment on the RFC and find out.
- nrc: Forbid import shadowing (under a feature gate). Feedback on the RFC was positive. I don't remember what the object ion was in the meeting...
- nmatsakis: I'm in favor of this, except for the feature gating. Why not just forbid it altogether?
- brson: Probably with the intent of eventually removing the gate?
- nmatsakis: Is there some pattern that requires import shadowing today?
- brson: Impossible to do some disambiguation...
- nmatsakis: Can rename.
- brson: Yes.
- nmatsakis: Long-term, if the plan of record is with the semantics I specificed for imports, I did not allow import shadowing. But, I did allow explicit names to shadow glob names. Maybe that's why the feature gate is there?
- brson: Should imports shadow crates in this RFC?
- nmatsakis: Nothing shadows anything else in this RFC. I'm in favor, except that I would remove the feature gate.
- nrc: I think the gate was just to make the transition smoother.
- brson: Yeah, otherwise have to implement deprecation, whereas the feature gate is free. Sounds like people are positive. Merge as-is? I'll do so.
- nrc: Refine the asm! extension. Suggestion was to do a string-based approach. I thought this is something we did not want to pursue, but might want to do something better with inline assembly, but i didn't know what. How do people feel about it?
- brson: Does this design completely change the asm extension?
- nrc: Yes.
- pcwalton: Postpone. I don't want to do a whole bunch of work on this for 1.0.
- huon: Could be written as an external extension that compiles down to the internal format LLVM expects if we have the AST node for it.
- brson: Seems nice that someone could make an asm2.
- nmatsakis: Yes, maybe somebody could even do a D-like integration, which would be nicer than both of these.
- brson: So, they should feel free to make asm2 instead?
- nmatsakis: We should make an AST node with no syntax! Just kidding. It feels like we don't want to do this RFC right now. And I agree with huon that maybe we want to have this done externally.
- huon: I can explain this one in the RFC.
- nrc: Ban private items in public APIs. So, a public function can't declare a private struct inside of it. Not a lot of positive feedback on this one, but seemed to be because it's used for a whole bunch of hacks. It's not clear we should support those hacks. I should have re-read this one before today... I think having private supertraits was how people were using this. Or like as an exception to the type system.
- aturon: That could be left in. The interesting case was people doing something like newtype, where you want the abstract type to implement all the same traits the concrete type supported. So, just exporting a private type gave the same effect. Niko, I think you were going to give this more thought?
- nmatsakis: No, and I'm feeling guilty right now. I'm trending positive on this issue. Not very good arguments for keeping it. It's sort of a weird thing.
- pnkfelix: What's your thought on the inverse feature gate to gradually move away from people doing this?
- nmatsakis: As a deprecation strategy?
- pnkfelix: Yes.
- nmatsakis: That makes some sense. Thinking about the newtype scenario...
- pcwalton: I'm pushing back, because of privacy getting more and more complex. There's a big debate on what we have for privacy. I feel like it's more important for privacy to be simple than to do what you want.
- nmatsakis: A question of where simplicity lies...
- pcwalton: It's already thousands of lines of code to handle.
- nmatsakis: My biggest concern is how we define the guarantees we're getting.
- pcwalton: Lots of people are saying privacy is about names in Rust and that's bad...
- nmatsakis: I'd like that you can write all types that can be inferred.
- pcwalton: I've never seen it as something that important. If privacy is about names and there are some types you can't write (e.g., unboxed closure expression have an anonymous type you can't write).
- nrc: Sometimes you have to annotate (like for collect on an iterator). Are there types where you need to do so?
- pcwalton: Returning an unboxed closure from a function.
- nmatsakis: Any place where you're legitimately returning a private type?
- nrc: Stops you from storing it? So people can use it but not store it?
- nmatsakis: They can store it in a generic type.
- pcwalton: My point is that this is nothing new.
- nmatsakis: I don't think unboxed closures are exactly comparable, because you declared the item private.
- pcwalton: I think there's a deep connection because of privacy being tied to abstract types.
- brson: Seems vague enough that we won't come to a conclusion today. Any more useful discussion to be had here?
- zwarich: I'd add that what privacy means is important for what guarantees you get from unsafe modules.
- nmatsakis: I agree - what Cameron said. Where privacy is really important is unsafe code leaking out.
- pcwalton: I think that this has problems for the same reason OCAP has problems. If you have a private function, you can leak it via a closure and there's little we can do about that.
- nmataskis: Matter of degree, though I agree you can.
- pcwalton: There are some battles that can't won, and if this is one of them, I'd like to do something simple.
- pnkfelix: I infer from your statements here that you feel these rules do not make privacy simpler?
- pcwalton: Hard to add anything that would make it simpler.
- zwarich: Easier to implement or easier to use? I don't think those are the same.
- pcwalton: Worse is better.
- pnkfelix: Seems simple.
- pcwalton: I'd argue impl. simplicity leads to simple use.
- nmatsakis: This RFC does not seem hard; it's a decl check, not use check.
- pcwalton: I won't stand in the way, but pushing back on more change, as I often do.
- brson: Niko you're waffling :-) I don't think we're going to come to a conclusion here...
- nmatsakis: I'm re-reading the RFC. I feel like it's a good idea. But I'd be happier if somebody else implemented it!
- pcwalton: Make it a lint instead of a hard rule?
- pnkfelix: It already is.
- pcwalton: I'm happier with complexity in lints than core language. Lints feel like a good place to fight battles that can't be won.
- nmatsakis: Compromise is to make the lint forbid and change it w.r.t. supertraits and so forth. Seems reasonable and allows people to keep using their hacks. I'm happy with that.
- pcwalton: I do feel a lint is the better place for this because I'm OK with unsound analyses, etc. in lints since the user can turn them off.
- nrc: Meta-question. If we have a lint that is going to be forbid and it's widely left on and we make it part of the language post-1.0?
- pcwalton: Yes. I'd want it to be warn. And not forbid, but deny. I don't want to get in a situation where nobody can make a compiler from the spec because the compiler has other things it checks. I think deny-default lints are indistinguishable from language features.
- nrc: But, you can turn them off. So if we think it ought to be a language feature, then a deny lint sounds like what we want, right?
- pcwalton: I've always felt we should be able to add lints post-1.0, but deny lints break code, so they would not be OK.
- nmatsakis: Yes, if we're calling it deny, why not make it an error?
- pcwalton: I prefer warn here.
- nmatsakis: So, status quo, with maybe some lint updates with new... I don't think this is a huge deal one way or another. Although I think it seems like a nice idea, we should probably leave it the way it is.
- pnkfelix: I think if we took the deprecation feature gate route, it'd give us a chance to revisit later...
- nmatsakis: I'd prefer to close it instead of revisiting.
- nrc: If it's the right thing to do, then we should do it. If we're not sure, then if it's not a lot of effort, we should be conservative so we can deny it later. But it's such a small thing that I don't feel it's worth more dwelling over.
- aturon: I agree completely.
- pcwalton: I won't stand in the way.
- nmatsakis: I feel like we should do it, then.
- brson: OK, let's do it! Niko, any changes to make?
- nmatsakis: Just private supertraits. I'm not as sympathetic to the newtype example. Let's just merge it!
- brson: Awesome.