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

Latest commit

 

History

History
299 lines (242 loc) · 19.9 KB

2014-11-18.md

File metadata and controls

299 lines (242 loc) · 19.9 KB
Raw

Agenda 2014-11-18

Attending

larsberg, zwarich, kmc, nrc, acrichto, nmatsakis, aturon, brson, pnkfelix, azita, steveklabnik, huon

Status

  • brson: automation, rel channel rfc
  • pnkfelix: drop + lifetimes; box + placement box
  • nrc: landing coercion removal, equals clauses for assoc types, macros
  • aturon: path, task->thread, conventions work, stabilization

Action Items

cmp/ops design

rust-lang/rfcs#439

  • aturon: Another RFC that's part of stabilization. Briefly, this makes the story about taking things byval vs. byref coherent in the comparison and operator traits. It makes most of the traits take things byval (since you can always implement them on reference types, so it's more general) and byval can let you be more efficient or have more options.
  • somebody: warble warble noise noise
  • aturon: Should be no loss in expressiveness. We're leaving open what versions of these traits we stabilize. Another change is to the slice notation. This was a separate pair of traits for various slice operators and we've realized we can support a nicer design where the .. notation stands by itself for expressing ranges, and indexing on the ranges works. Lots of feedback in the RFC, overwhelmingly positive. Pretty clear improvement across the board. Little more work to the 1.0 schedule, but we need to stabilize these APIs, so we had to do something here.
  • acrichto: On the range function, will we remove it from the prelude in favor of .. notation?
  • aturon: Probably . Doesn't go into the ramifications. Since you have the .. notation, you can do for x in ..n. Now we have more options in iterators: step, etc. This notation does not cover all the cases, but we can remove stuff from the prelude.
  • pnkfelix: .. or ...?
  • aturon: Just .., as it replaces the slice notation. Could always add inclusive later, backwards-compatibly.
  • brson: Slices do not support the ... notation?
  • aturon: Correct.
  • brson: And also empty slice notation?
  • aturon: Yes. That's an issue we may want to revisit: it's treated as indexing with the unit type, which you can implement as_slice for. So you'll have no regression, though if we decide to have the DeRef coercions, we'll want to revisit.
  • pnkfelix: Not the unit type, but with a fresh unit type, zero-sized struct?
  • aturon: Yes. It's not literally THE unit type...
  • nmatsakis: But not a unique type at compile time...
  • aturon: Correct. Also, contention around there being several different types of notation for inclusive vs. exclusive, etc. Right now, those each generate different types. Huonw was suggesting we could collapse them together, but that might rule out being able to statically prohibit some cases.
  • brson: I'm happy with this. Clarifications/objections?
  • acrichto: dibs

TLS

rust-lang/rfcs#461

  • acrichto: Adding a TLS module. Some of the APIs have unsafetiness. Have changed the get method to a with_ method, which requires a closure, etc. but I think it's better. We currently have some unsafety, but nmatsakis has some ideas for how to make it safer. It's kind like how today's destructors are unsafe today and it's manifesting in some cases. We could paper over it, but I'd like to make TLS safe before landing this.
  • brson: Plan is not to deprecate the existing APIs? Just hard break it for users?
  • acrichto: Could leave it deprecated for now. Runtime removal will take a few more days. Alternative is similar to Rc<RefCell<Option>>.
  • nmatsakis: The change to with is appealing because it makes the APIs similar. I think we can make the get work as well, with a few changes.
  • acrichto: I've already done this change in a branch. rustdoc was the worst offender, but I made it through the crate without many changes.
  • nmatsakis: Could have variants for Copy and Clone to avoid having to write the stupid thing and make the conversion easier.
  • acrichto: Also, all of these methods yield Option<&T>. Static variant is because it's currently being destructed. Another option is to yield the &T to the closure, which turned out pretty nice in the branch that I did. Should we fail internally if it's not a Some?
  • brson: strcat felt it should be a logic error. Agreed?
  • acrichto: Seems right.
  • brson: Is it statically possible to avoid this case?
  • acrichto: I added an internal function to be able to test if you're in the middle of destruction, which is when it can be None.
  • nmatsakis: panic! or unreference the option?
  • acrichto: panic.
  • nmatsakis: Good, I felt the unreference was always a pain.
  • acrichto: Should just one of the scoped/get variants have an option?
  • nmatsakis: Seems more like an ergonomic argument than a safety one.
  • brson: Iron this out offline?
  • nmatsakis: Yes, minor point.
  • brson: Still experimental?
  • acrichto: Yes.
  • aturon: In favor! I'll merge.

restrict identifiers immediately after literals

rust-lang/rfcs#463

  • nrc: RFC that makes our treatment of literals less ad-hoc. You could currently stick identifiers directly after a literal and it gets parsed as a literal. The suffixes for numerics and strings, for example. This RFC says rather than special-casing, any literal following an identifier gets parsed as a single thing. Seems good because it makes parsing of literals less ad-hoc and futureproofs and lets macros handle U2 or U1 and lower into proper Rust. Downside is that if people write literals and then an identifier, that will no longer parse. Can't imagine people do that often.
  • pcwalton: In general, wary of accepting RFCs because we think nobody will be burned by them. I'm working on one that should break no code that has become a 5k line diff...
  • nmatsakis: But this doesn't even parse today, does it?
  • pcwalton: Macros can. But we could also just say "macros are unstable anyway." Would prefer to make this post-1.0 if we can.
  • nrc: Seems like it should be easy to implement and find out if it breaks code.
  • nmatsakis: I don't expect it to break code in the compiler. Not sure I would have said that about the other PR, though. I'd be OK with taking this if somebody else does it.
  • brson: Hopefully huonw will do it!
  • nrc: Should be a small parser tweak.
  • brson: pcwalton, you objecting?
  • pcwalton: I'm not objecting to doing the work, but am objecting to making it a blocking 1.0 issue.
  • nrc: I'll merge it.

tuple indexing, if let, while let

rust-lang/rfcs#450

  • acrichto: WE should unfeaturegate it.
  • aturon: I thought there were some questions about how it desugared, interacted with borrowchk, etc.
  • brson: Desugaring, or is it deeply integrated?
  • nmatsakis: Desugar.
  • pcwalton: People using it?
  • nmatsakis: Yes. Though not me, because I never know if it's landed in the version I'm using. I'm pretty happy with the desugaring.
  • brson: People had lots of questions about if let and else cases on #rust.
  • nmatsakis: I don't know the conversation, but was it exhaustiveness? We don't check for it in those cases. Surprise!
  • aturon: My only hesitation here is that this was not widely used, and before we unfeaturegate it, we should make sure we're happy with it. If somebody's already done that, I'm fine.
  • brson: What was the motivation?
  • acrichto: Allows deprecation of the TupleN traits.
  • brson: Also while let?
  • acrichto: Yes.
  • nmatsakis: They come as a pair. I'll look at the desugaring.
  • aturon: I'd be happy to accept provisionally, and nmatsakis can ungate after he investigations.
  • brson: It's nmatsakis' job, then!
  • pnkfelix: My only worry is I don't know what while let's semantics ended up being - e.g., is there an else block?

naming conventions

rust-lang/rfcs#430

  • aturon: Several conventions I wrote up that were from the wiki and defacto. This RFC is standardizing them. snake case for values; camel case for types; etc. However, one twist is that since these rules we've grown constants in addition to statics. Original RFC didn't make a distinction: all SCREAMING_SNAKE_CASE. Some discussion of having const vs. static being different. Counterproposal: keep statics screaming; make constants use camel. Rationale is that constants are closer to enum variants. I can buy that; however, it's not a super strong argument and that is a LOT of churn. My perspective is to stay with the status quo. acrichto determined precedent in other langauges and determined we could choose literally anything and find a justification.
  • nmatsakis: One more is that the convention for constructors is new or new_with_more_details. Do we write that?
  • pcwalton: No. We write with_, instead.
  • nmatsakis: I see several as new_with_ and several as with_. I like with_. But the const/static is not worth doing.
  • brson: Good. This also makes a decision on unwrap final!
  • aturon: kballard proposed that if you look where we use unwrap right now (option and result) and maybe a few other cases, in the others, you can use into_inner or into_stream conventions. That makes unwrap (a panic thing) and into_ (which does not panic!), which is really nice. Good way of sidestepping the whole assert! conversation with the community.
  • nmatsakis: Brilliant.
  • brson: I'm in.
  • aturon: Status quo it is!
  • brson: I will mege it.

servo update

  • larsberg: skip; I give up on stupid vidyo mic! acrichto commented in the one bug we have.
  • kmc: bits of llvm end up linked to plugins then asserts because their static ctors register command line arguments. #18671 (rust-lang/rust#18671 )
  • acrichto: seems like the link flags may be wrong somewhere. need a repro. i got an error with a plugin because i wasn't building as a dynamic library
  • kmc: what does 'plugin=true' do in cargo?
  • acrichto: flags for host architecture, dynamic lib, etc.
  • kmc: we may be missing that

struct variants

struct variants Q: force match via struct pattern? (pnkfelix) http://is.gd/uUVO80

  • pnkfelix: Making sure we got some stuff right. Playpen doesn't have it not feature gated, but I can show the problem. Would you expect struct variants to be forced as structs using matching, or are we expecting tuple-style pattern matching on struct variants?
  • aturon: That is... surprising.
  • pnkfelix: I was also surprised. I can file a bug, but wanted to make sure that's not intentional.
  • pcwalton: P-backcompat-lang. Danger of un-featuregating things

for syntax for high-order lifetimes

rust-lang/rfcs#387 (comment)

  • pnkfelix: Changed the type constructor for functions, but there's no corresponding definition form. So do you use the old style for definitions, but get warned for it? I was scanning the RFC, and it seems like an inconsistency between the two forms. Minor detail.
  • nmatsakis: Yes, it seems natural to have only one option, and for seemed to be the one that scales up. Though we could permit the older fn keyword form if we wanted to.
  • pnkfelix: Not a problem to have the type constructor look different from the definition?
  • nmatsakis: Doesn't bother me, though we try not to do it if we don't have to.
  • pnkfelix: Does everybody understand wha tI'm talking about?
  • pcwalton: Would be helpful.
  • pnkfelix: If you have a higher-order function:
  fn foo(incr: fn<'a>(&'a mut int) -> &'a mut int, x: int)

==> warns: use syntax instead:

  fn foo(incr: for<'a> fn(&'a mut int) -> &'a mut int, x: int)
  • pnkfelix: Strange thing is that you can't then write analogous code for the thing you want to pass in, as it's invalid syntax for the Item definition:
for <'a> fn my_incr(x: &'a mut int) -> &'a mut { *x = *x + 1; x }

==> is rejected (must write instead:)

fn my_incr<'a>(x: &'a mut int) -> &'a mut { *x = *x + 1; x }
  • aturon: In the long run, you won't write fn, you'll write Fn, right? These are going to diverge even more. Once we do that, will you even be tempted to change your item definition?
  • nmatsakis: The fn type exists under both proposals, but it will have less use vs. an unboxed function with a static bound. I thought it would be better to have only one syntax, and I think we can't use the random attachment of bound lifetimes to trait names - only for works for everything.
  • pnkfelix: Unacceptale to change the definition form of fn to require the for syntax?
  • nmatsakis: Would be a sweeping change...
  • pnkfelix: I'm not proposing that. Just making sure everybody was ok with this. I feel better with the Fn form migration.
  • nmatsakis: fn will not have much point, going forward.
  • pnkfelix: That's all!

macros

  • nrc: Can we have a separate macros meeting focused on 1.0? There is a LOT to discuss.
  • kmc: Agreed.
  • nmatsakis: Let's schedule it.
  • kmc: We can defer the bulk of the macros proposal, but if we change macro_rules! name as a separate RFC, we should make sure there's time before 1.0.
  • nmatsakis: No requirement to do the name change for 1.0 (or at all).
  • brson: macro_rules, there are still a lot of outstanding questions. Volunteer?
  • nrc: I will get it scheduled this week.
  • nmatsakis: Agree that for large things like this we should have a separate meeting.
  • nrc: I'll send mail around after this meeting.
  • brson: Was that primarily what you wanted to bring up, kmc?
  • kmc: There was also a lot of discussion on whether if we make syntactic changes with semantic changes. People seemed to be in favor, but wanted to ask because it plays into how we could potentially split up the work.
  • nrc: What are the syntax changes?
  • kmc: item macro invocation syntax, which I'm happy to defer because it just addresses macros that define macros. The other is attributes vs. keywords for scoping stuff. I just want to avoid making everybody rewrite and then rewrite again.
  • nmatsakis: If we add syntactic sugar in the future, you're not forced to use it...
  • brson: Specific point on the syntax of import/export we do want to address, right?
  • nmatsakis: Yes.
  • kmc: Suppose acceptable to keep our ugly attributes today, and just add the keywords later back-compat. Rather not ship 1.0 with semantic cleanups but keeping the ugly syntax. Agree it's tricky. Simple syntactic changes can have huge consequences.
  • brson: Great; can discuss in detail at the meeting later this week.

plus in type parameter

rust-lang/rfcs#438

  • nmatsakis: I wanted to change the way we parse types to achieve two goals: 1, align the precedence of operators in the type and expression grammar. The other is to eliminate ambiguities. The second question is what was missed in the last meeting. If I have:
fn foo<F>(f: F)
    where F: FnOnce(&int) -> &Object + Send // ambig
    where F: (FnOnce(&int) -> &Object) + Send
    where F: FnOnce(&int) -> &(Object + Send) // today 
{ }
  • nmatsakis: Function with a bound using the new association. It's unclear how to parse it! It doesn't match my expectations today that a unary operator & binds looser than a binary operator +. In terms of the grammar I gave, there's a distinction between the types in arguments:
In expr grammar: *(x+y) not *x + y

In type grammar that I gave:
Foo(A,B) -> C
A and B are "SUM"
C is "TYPE"
Foo<A,B>
Foo<Object+Send>

F: Fn(A) -> B + Send equivalent to:
F: (Fn(A) -> B) + Send
  • nmatsakis: And you don't need parens.
  • pnkfelix: I don't find that intuitive. Could have seen it the other way equally well.
  • nmatsakis: B + Send is unsized and can't be returned, so always guaranteed to be an error, so definitely not the way you want that example to parse.
  • brson: Always guaranteed to be a type error?
  • nmatsakis: Today. Maybe generalized union types in the future. Would require more sigil-wrangling and precedence-wrangling. But we don't have them today.
  • brson: What's the impact of this change?
  • nmatsakis: Will require some parens. Not uncommon to write:
&'a Foo+'a //today
&'a (Foo+'a) //tomorrow
  • nmatsakis: Most annoying change.
  • brson: Migration path?
  • nmatsakis: Can write the parens today
  • brson: Will this be baffling to users?
  • nmatsakis: Can give warnings. Do in two phases.
  • brson: Not understanding the fallout, that strategy seems prudent to me.
  • nmatsakis: Agreed.
  • aturon: I'm OK with the change to &. Just weren't sure about the rationale for the precedence between -> and +, and the rationale is "it makes more sense," which seems fine.
  • pnkfelix: I won't stand in the way of this change, I guess.
  • brson: I will merge this.

Better shepherding

  • nmatsakis: We're not making maximum use of shepherding process overall. Sometimes, there are things on the agenda that have not been fully shepherded. pubs and traits has not had a lot of motion. Macros in a separate meeting is a good example of doing things the right way. Not sure how to do this consenus-building outside of the meeting, but we should do so.
  • aturon: Key thing is for the shepherd to identify stakeholders and talk with them before the meeting. Sometimes there are surprise stakeholders, which is why the meeting is good.
  • nrc: I think that's the common case for where we spend time. Unexpected stakeholders. On idea is that if there's somethign ready to come to the meeting, we could announce it Monday for people to review.
  • nmatsakis: The more notice we have on the agenda, the better. I know it's hard to remember to look at the agenda, stay educated, etc.
  • nrc: Right now, it's just the day before.
  • zwarich: Could also have putting your item in the agenda = covered earlier in the meeting!
  • brson: Definitely true that if there is an item that will sail through it comes up first in the meeting.
  • aturon: There's also an etherpad for RFC planning. Shepherds could put info about their RFCs in that. I'll send the link around again.
  • azita: Planning meeting is the day before, right? Do you review the agenda then?
  • nmatsakis: Could do so...
  • nrc: It doesn't have the people in this meeting. It's a minority of this meeting.
  • azita: Could put things up on the agenda for the planning meeting to reorder/prioritize...
  • nmatsakis: Anyway, point was that shepherds should try to build consensus :-)