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

Latest commit

 

History

History
211 lines (181 loc) · 16.9 KB

2014-08-05.md

File metadata and controls

211 lines (181 loc) · 16.9 KB
Raw

Agenda 8/5/2014

Attending

nrc, larsberg, jack, nmatsakis, aturon, pcwalton, pnkfelix, acrichto, huon, brson, azita, spernsteiner

Status

  • nrc: rebasing hell
  • acrichto: git2-rs, cargo-doc, lots of windows bugs now
  • aturon: design & RFCs for workweek, conventions cleanup, collections
  • pnkfelix: nonzeroing drop, quote_expr! (#15750)
  • brson: admin, ssl, gcc, perf, seo, training
  • nmatsakis: blogs, region safety w/ objects/type-parameters, traits
  • pcwalton: associated items, where clauses(?), backwards-incompatible language changes

Action Items

Replace use id = path

  • pnkfelix: Changes our syntax for renaming imports. The motivation is to make everything line up more nicely, in terms of paths on the LHS in columns and import ids on the RHS. Community seems universally positive, except for some alternatives & extensions. I'm willing to implement this.
  • nmatsakis: Reading the RFC, it doesn't work for multiple renames. Incorporate?
  • pnkfelix: We don't do it today.
  • brson: Is it that desireable? I haven't felt that pain.
  • nmatsakis: We can do it later.
  • pnkfelix: Mainly for globs. When you want a whole collection of things renamed, in some regexp form.
  • nmatsakis: Also, this syntax gives us the room to go there, which the current doesn't.
  • acrichto: This also says changing the extern crate syntax?
  • pnkfelix: Yes, somebody thought it would be more consistent there, too. That's the only open question here. 'extern crate' also allows renaming (you can put id=string). Kevin pointed out that if we change it for imports, we should do it for extern crate, too. I did the same transformation there. But, TBH, if there are any objections, we can take that back.
  • brson: It's mainly for consistency, right? But the syntax is not the same because extern crate allows you to import a string name, which is not an ident.
  • pnkfelix: There was a suggestion to add extern crate ident as ident, which would then make them sort of similar. I listed it in the alternatives in the RFC, but that is orthogonal and could be a separate RFC. They could be the same syntax, but they aren't.
  • brson: Anybody have objections to the main thrust?
  • all: no.
  • nmatsakis: I like the syntax change. I don't have a strong opinion on the extern crate bit.
  • brson: Does anybody?
  • pcwalton: I think Kevin is correct and it should be changed.
  • pnkfelix: Where do the link attributes go?
  • acrichto: We don't have those anymore.
  • nmatsakis: I think Kevin is correct. I would never guess the equals syntax.
  • brson: Can we have the deprecation plan if we do this?
  • pnkfelix: Yes.
  • brson: OK. nmatasakis, will you merge this?
  • nmatsakis: Yes.

Servo

  • larsberg: two issues: (missed). Luqman and (?) are working on them
  • larsberg: other blocking html parser, felix is looking at that
  • larsberg: We're also doing a Rust upgrade and struggling with the lifetime issues, but don't have any issues to log right now.
  • jack: Yet :-)

&mut patterns

  • huon: Proposing that we use &mut <pattern> instead of & <pattern>.
  • pcwalton: Right thing to do.
  • nmatsakis: You can coerce &mut to & in some situations, and I don't know why noone has complained about it before. I think it's OK, as this probably don't occur that frequently anyway. We currently know the type that we're matching against when matching a pattern, but this would reduce that requirement. There might be an issue around Box patterns. Seems more consistent, but also more wordy. Any idea how frequently this occurs?
  • huon: I could instrument the compiler and try to work it out, if we want some data.
  • acrichto: I'd be interested to see, like on the iterating over a reference to a tuple and want to mutate the item in the tuple.
  • nmatsakis: Might have an alternative of accepting both. The tuple example looks a lot better now, to me. Having to write &mut ref x seems bad anyway.
  • pcwalton: The way it is now is not consistent.
  • acrichto: The drawback listed is a drawback, but I don't think it will come up that often.
  • nmatsakis: Should be possible to grep for ref muts that occur inside an &.
  • brson: Have huon gather some data on this for next week?
  • huon: 21 instance of it, with 8 in bitv, which could be abbreviated with a method.
  • nmatsakis: Compared to how many without?
  • huon: 34,000 instances of & in the codebase! 465 that are & ref.
  • nmatsakis: Pretty rare.
  • acrichto: Let's gather some formal data, maybe on Servo as well.
  • nmatsakis: I'm with patrick on this, but also torn that this might be needlessly verbose.
  • brson: Another week to think about it. Huon gather some data and we'll com back to it.

RFC 177 static mut access

  • acrichto: Discussion has died down. This kind of functionality is needed - a safe static lock or static int. This is one way; the other is to have const static vs. static mut distinction. We sort of have the distinction today, but I'm not totally convinced that going to three kinds of statics is worth it for this kind of change.
  • nmatsakis: I should comment on this. I think there's a good argument for having const as a separate thing. But there's a separate œuestion if we want to make a change in the short-term. We have const in the language today in the form of enum variants (rvalues when you reference them, no variables involved, etc.). You could make them generic and it makes sense, unlike with a static variable, which is conceptually a memory location. Inline never is also weird on it. OTOH, having three things has always bugged me. If we went this way, you'd always use const, unless you had a global count/lock, in which case you'd use static. You'd never use static mut. So, really, we'd just introduce const.
  • pcwalton: Also useful in embedded kernel usecase where you don't have threads.
  • acrichto: We'd keep it around.
  • nmatsakis: I'm not saying to remove it. Even in the kernel, you might not want to use it and instead just use static to avoid an extra unsafe.
  • brson: Do we want to do this design in order to have something that works to hedge our bets?
  • nmatsakis: If we did the const thing, it'd require an RFC of its own. I would be curious to hear what other people feel, given the limited feedback on the RFC. Most of the feedback there is around objections to static mut, which I don't agree with.
  • acrichto: If we go down the route of an RFC for const, then there's no point in doing this. No reason to special-case Share.
  • brson: nrc, opinion?
  • nrc: I think we should do it the proper way or at least write an RFC for the const suggestion.
  • nmatsakis: I'll write up an RFC and see how it goes. We can talk about it some at the workweek, too.
  • pcwalton: I like const. I don't like scope creep, but I won't stand in its way.
  • nmatsakis: This seems fairly minor.
  • nrc: Do these RFCs get rid of the different behavior on inline never?
  • nmatsakis: const does
  • nrc: Then I'm even more in favor of it.
  • nmatsakis: static would always be a variable and never inlined. You can take its address and get a consistent thing.
  • brson: Let's make this an agenda item for the workweek, then.

where clauses

  • pcwalton: I want to implement them. At least the part that is isomorphic to what we have today. Then, I'd like to start moving stuff over where it makes sense. I don't want to yet implement stuff that lets you <types, parameters, bounds> that doesn't desugar. This might be stepping on the toes of trait reform proposals too much.
  • nmatsakis: I've done the other half of this work in trait reform. It flattens to a list of bounds not associated with the type parameter.
  • pcwalton: Then we're attacking this from both ends. I'm looking forward to readability of where clauses. I'd like to do an experiment of removing the old thing entirely. From scheduling point of view, it's all predicated on implementing where clauses.
  • brson: Accept that RFC now?
  • nrc: RFC #135
  • nmatsakis: No major changes that I remember.
  • nrc: Yes, feedback is all positive, just minor changes required.
  • brson: All in favor? pnkfelix?
  • pnkfelix: lgtm
  • nmatsakis: I will make some updates to it - one minor clarification.
  • pcwalton: I'll try to get it by EOW.

impls next to types

  • brson: What's the state?
  • pcwalton: I think I was supposed to merge it.
  • acrichto: Yes, we agreed last week to merge it.

More sylistic lints

  • acrichto: Somebody put them together; this pull has been open for a while. There are also lint groups now. What are people's thoughts on a lint controlling many levels of sublints.
  • pcwalton: Seems fine to me. Who could object?
  • nmatsakis: Me. I've heard people complain that when you use -Wall, they can't add things to it because it would break old code. Do we want to give names that have versioning in them? e.g., BadStyle1.0? I think the general idea of groups is a good one.
  • pcwalton: I think clang have a -Weverything, which is REALLY all. There's also -Wmost and -Wextra.
  • nmatsakis: Maybe we give them names and then put a version number on your files?
  • pcwalton: Just name them All1.0 or something. I think gcc/clang has shown you'll otherwise defacto version with new names.
  • steve: Tied to the language level, so you can only change the lint value on backwards-incompatible levels? So All changes at 2.0?
  • nmatsakis: Can you forbid certain groups? So you'd say all and then forbid the new ones? Hrm. Seems like we should merge the RFC and decide the policy later.
  • brson: Sounds good to me.
  • acrichto: I'll do it.
  • pnkfelix: There's an RFC?
  • acrichto: Just a PR.

127: optin builtin traits #2

  • nmatsakis: Talked about this a little last week. Roughly, it allows you to write recursive traits. Designate some as marker traits, so the compiler considers it implemented unless something has opted out. The main feedback was around pcwalton preferring an attribute on the trait instead of new syntax. The other feedback from pnkfelix was that the built-in traits are no longer so built-in, and we'd have to justify our rules around them being special. The plan is that object references would be able to handle more than one, but needs to be written up. You should be able to have object references to multiple traits that are just any old ones. I could see saying that we need to write up that puzzle first, because otherwise Send and Share remain special in some ways.
  • pnkfelix: yeah, that's what I was asking for - such a writeup.
  • nmatsakis: I don't mind doing that. Were there such a write-up, are there other objections?
  • brson: There are several new mechanics to accommodate a usecase many people aren't even aware of. Is it worth it? Though we should solve this in some way.
  • nmatsakis: I'd like this not to be a 1.0 thing. It's a nice mechanism that we don't need right now. I'm not yet sure how to make the current compiler rules forward-compatible, specifically around unsafe types. We could keep the impl as it is now, but have unsafe types require opting in to be sendable, and have that feature gated on this mechanism. Or we allow you to opt infor those cases but not build the other infrastructure. Might let us hedge our bets. So, implement the opt-in rules and make unsafe things not Send+Share by default.
  • brson: Other opinions about this?
  • acrichto: I agree that it's a lot of stuff to add. It all makes sense, and I agree that it would be nice to do the minimum for 1.0.
  • nmatsakis: How about I adjust the RFC to include a timeline/1.0 strategy. Maybe we'll bring that in.
  • pnkfelix: Very good idea.
  • brson: Nobody's opposed to this.
  • nmatsakis: Alternative is should we continue with the current strategy?
  • aturon: I'd definitely agree that this is the right direciton, but doing the conservative thing for 1.0 is great.
  • erickt: Having unsafe things opt out seems great, and can be behind a feature flag.
  • nmatsakis: Boils down to people implementing Arc, etc. They're already using feature flags anyway.
  • brson: Sounds like nmatsakis should update this a little more before we approve it.
  • nmatsakis: I'll sketch out a 1.0 path. Maybe I'll delegate it :-)

22 - deserializing to a stream

  • erickt: I recently landed a bunch of perf. enhancements in Rust, so now the json serializer is as fast as the fastest C one. I've written macro extensions to serialize/deserialize my file format. Been validating by porting over toml, and next step will be the message pack to make sure what I've done works with other formats. Also contemplating whether this serialization library could live as a top-level independent from rust library. If we can resolve figuring out how to get the compiler to use it using the syntax extensions works great. I'd love not to have these in libsyntax.
  • brson: So you'd rather serialization outside the repo or just not in the compiler?
  • erickt: Either. I'd like to push for moving out the syntax extensions from libsyntax either way.
  • nmatsakis: Until we're ready to commit to our syntax extension infra (which is nowhere close), they'll be in the repo and tightly linked. But that is the direciton we'd all like to go
  • brson: But, rustc needs a serializer, and so the bootstrapping in stage1 needs it to keep working. If we move to it, what's the transition plan?
  • erickt: They can both be active - different names & interfaces. My plan is to port all users of the old serializer to the new one as long as there aren't other people using these old libraries, it should be relatively smooth.
  • brson: When?
  • erickt: Between now and the workweek. Hopefully I'll be able to talk in person on how all this is working and update the RFC and submit a PR then.
  • brson: Does toml mean bringing support into the tree?
  • erickt: No, I have a fork of toml I pull in through cargo.
  • nmatsakis: When do you want to port the metadata in rustc to use it?
  • erickt: I was going to port rbml over, but I don't know how hard it would be to port it over to message pack.
  • nmatsakis: I did it once and it wasn't too hard, but it was slower and bigger. You might have addressed those.
  • erickt: Probably still big, but it should be faster. What format?
  • nmatsakis: i don't care, other than smallest+fastest.
  • erickt: I'll see. Could eventually use something like captain proto or protocol buffers that might be faster.
  • nmatsakis: Once we're using this infrastructure, we'll have more options.
  • nrc: Wait for workweek?
  • erickt: Yes.

UFCS #132

  • nmatsakis: No outstanding problems with this.
  • nrc: Right, but we haven't accepted it.
  • aturon: Working on associated types, I've been assuming we would use a similar syntax for associated types, which mostly works wel, but there's ambiguity with higher-ranked types. Closures can be < 'a > and introduces a higher-rank variable. That's ambiguous with...
  • nmatsakis: No it's not. Just annoying to parse. There isn't a type that begins with a tick, is there? Unless we get rid of tick.
  • aturon: If we had other forms than just lifetimes, the conflict would become more severe.
  • nmatsakis: Technically parseable with one char of lookahead, but requires a convoluted grammar. I'm inclined to possibly change that higher-rank type syntax. It's not widely used or liked today. I don't know what to, though. But I'm willing to cross that bridge when we come to it.
  • nrc: Other objections?
  • acrichto: Let's do it.
  • brson: huon, how would you like to do some stuff? You can merge the UFCS RFC.
  • huon: OK.

Allow {} for structs with no fields? RFC 147

  • nrc: Lots of people in favor and lots firmly against. We need to make a call.
  • brson: Primary constraint here is macros?
  • nrc: Multiple ways of doing the same thing.
  • brson: Motivation, I mean?
  • nrc: Yes, macros.
  • nmatsakis: It seems like the conservative thing is to keep the design as-is, but I lack a strong argument for such a minor point. I think we should close this RFC because it's the conservative path forward, unless anyone is prepared to strongly make the case the other way?
  • nrc: I agree with the consistency argument. I got called out a lot about using ; instead of {} when I was first learning Rust.
  • brson: I sympathize with the macros motivation, though.
  • zwarich: There's nothing that would be blocked by not having this, but if you're generating Rust from either with macros or code, it's nice if you don't have to handle empty-list separately.
  • brson: Then let's close this.