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

Latest commit

 

History

History
175 lines (142 loc) · 13.4 KB

2014-12-16.md

File metadata and controls

175 lines (142 loc) · 13.4 KB

Agenda 2014-12-16

Attending

steveklabnik, pnkfelix, acrichto, nmatsakis, larsberg, zwarich, aturon, nrc, erickt, pcwalton

Status

  • brson: combined install and misc automation
  • acrichto: stability, search paths
  • pnkfelix: box/Box::new data, dtors+lifetimes
  • aturon: stability, new path impl, RFC revisions
  • nrc: range syntax, assoc type stuff, coercions, highfive

Action Items

Friend of the Tree

Gábor Lehel (glaebhoerl)

Gabor's major contributions to Rust have been in the area of language design. In the last year he has produced a number of very high quality RFCs, and though many of them of not yet been accepted, his ideas are often thought-provoking and have had a strong influence on the direction of the language. His trait based exception handling RFC was particularly innovative, as well that for future-proofing checked arithmetic. Gabor is an exceedingly clever Friend of the Tree.

Issue numbers in FIXMES

rust-lang/rust#19546

  • nrc: What was decided last week?
  • nmatsakis: I said I like FIXME where it gave you a hard error, but now I can do //TODO and get the same behavior, so I was satisfied (I can leave myself bombs). Lots of concerns that if we make it a hard rule, we'll have lots of spurious issues.
  • pnkfelix: Every time we do this, pcwalton said that people instead create markers without issue numbers.
  • brson: I often want to make a FIXME note to myself without an issue.
  • nrc: I agree you want something without it, but I'd like something with an issue number, too, so you can grep for it.
  • nmatsakis: Strategy is to funnel towards FIXME (instead of XXX:), but it doesn't require an issue number. Use // TODO until the last possible moment, at which point you choose whether to add a FIXME with or without issue number or not. If we required an issue number, I would avoid putting in a FIXME. Not sure it's the best strategy, but it's how the current strategy has worked out.
  • nrc: I get irritated by finding a FIXME in the code with a one-liner that makes sense only to the author. For me, it's to discourage pointless FIXMEs that others don't understand. It's meant to be a partially technical issue to encourage people to do a better job of this.
  • brson: I used to often have a strong idea of what I wanted the code to look like later that were personal notes for later fixup. Admittedly, they ended up not getting finished sometimes...
  • nmatsakis: I use TODO for that. MAybe not a big problem now that tidy runs at the end... if anything else, I just don't want to do a ton of work going through the current FIXMEs and cleaning them up.
  • brson: Last time we tried to do that, it was a disaster.
  • nrc: Kinda feel like we want TODO (which is before we land this) and FIXME (which I will fix at some point in the future). Maybe want something that's FIXSOONISH? Can't use TODO becacuse tidy prevents you from landing with it. I'm talking about things you plan to fix in the next PR or two...
  • nmatsakis: Those are a lie.
  • nrc: Such are the FIXMEs without issue numbers today. Even with a name, often have no idea what is going on.
  • nmatsakis: Could also instill some reviewing discipline around reviewing FIXMEs.
  • nrc: Always make sense at the time, but 6 months later, it's hard.
  • nmatsakis: Only way to fix it now would be to institute the policy would be to start it and sed out FIXME for NOTE, but equally pointless.
  • pnkfelix: Maybe add ISSUE?
  • nrc: Lots of FIXMEs with issue numbers already that we'd have to fix.
  • pnkfelix: Don't have to.
  • nrc: I'd want to! Hrm, I feel like this discussion is not going anywhere...

nullable extern fns

  • sfackler: "nullability of extern fn pointers come up among the core team recently? right now they're not nullable so you have to use Option<extern "C" fn()> in FFI declarations which seems weird/bad, especially since 0 isn't the only "special invalid" value that C libraries use for function pointers"
  • aturon: Promised we would discuss this topic at the meeting this week and get back to him on it.
  • brson: I remember this has come up before, but I don't remember the arguments.
  • steveklabnik: Either we do what C does or what Rust does, they're inconsistent with each other, and this is about possibly papering over this bit of weirdness
  • acrichto: function pointers are either raw or an option. But I don't feel like function points should be nullable...
  • aturon: If you want to have multiple nullable values, you should have a void*, but try not to pollute the type with it.
  • nmatsaskis: Special tokens?
  • pnkfelix: 0, -1, etc. Things that can't be a pointer value.
  • acrichto: Many APIs where small integers have special values, and everything else is a function pointer. It's always unsafe to call extern functions. If we want to satisfy this use case of tokens, we need to have a jump table with all the tokens, so I'm not sure that supporting nullable helps us because we'd still have to check on every call.
  • nmatsakis: Calilng it would have to be unsafe. I like it how it is. As long as the Option optimization works fine, that is.

Servo blockers

  • larsberg: about to land 1-mo old rust upgrade. gets enum namespace changes. then runtime removal - should be easy. probably not moving to master because of unboxed closure instability
  • nmatsakis: transition story for proc should get smoother this week, so it behooves you to wait
  • larsberg: no blocking bugs. feedback from new contributors were shocked build stores stuff in home directory. probably will file bugs to make cargo operate in modes that don't spew stuff all over, not contact github, etc. not hi priority

collections reform take 2

rust-lang/rfcs#509

  • aturon: Not too big. It's a follow-up to the earlier RFC with some cleanup work. One thing this does is propose a stabilization story for our existing collections. The previous one set out what the APIs should look like, but didn't say whether we should e.g. ,have 4 different kinds of maps in Rust 1.0. This is proposing that we remove a handful of existing ones that are undermaintained/underperforming. Includes enum set, treeset/treemap, trieset/triemap. And bitflags. Shipping with a single hashmap/hashset and single btreemap, based on all the bstrie stuff. Just wanted to give people a heads-up on some of those removals.
  • nmatsakis: What's the plan for the compiler dependencies?
  • aturon: Bitflags only used in one place an dit's about to be removed.
  • nmatsakis: It's in the compiler in various places.
  • pcwalton: And it's all over the place in servo.
  • aturon: It's all just being moved out into cargo.
  • nmatsakis: I guess we can just move a copy back into the compiler; that's where it used to be. Trivial to work around.
  • erickt: Could also add a git submodule into the compiler on collect.rs. Been wanting to do it for libserialize if we pull it out of the distribution.
  • aturon: Main ones we want out of the distro are the treemap and triemap, as they impose a maintenance burden. Others could be private/internal for the timebeing.
  • brson: btree map exposes the b-ness of the tree?
  • aturon: Only if you instantiate via the WithB constructor (which will not be stable for 1.0). Part of the question is if we'll have multiple types of trees.
  • brson: Calling it btreemap does limit your implementation options... -nmatsakis: Seems like specifying values of b is useful.
  • aturon: Some type system changes might change the signature, so reluctant to stabilize. It's not obvious to me that it's the business of std to provide anything other than best-of-breed maps/trees. Anything optimized should be in external libraries. I'd be in favor of renaming btree and just calling it a tree.
  • arichto: Same for BinaryHeap back to PriorityQueue?
  • aturon: Trying to find a middle road here. Distinguishing HashMap and TreeMap. Wanted to keep the PriorityQueue name reserved for a trait later.
  • nmatsakis: TreeMap and HashMap expose different interfaces; e.g., TreeMap is sorted, right?
  • aturon: Yes. Maybe could have OrderedMap trait instead?
  • nmatsakis: I like TreeMap.
  • aturon: Lots of minor API tweaks, if you're interested. More substantial revamp of entry API from Gankro (which has consensus). Only other thing to raise is around the capacity semantics for VecMap (which used to be SmallIntMap). If you care, voice your opinion in the RFC. I anticipate trying to accept this in the near future, so please look soon.

prelude cleanup

  • acrichto: I have an RFC to stablize it by categorizing the prelude into things to keep / toss. Affects literally all the code. Tries to trash things not used often (e.g., tuple traits and ops traits and ascii and cstr and a few other little things). Path is the big one and so is comm. Taking comm out reflects how Rust is not tied to any concurrency primitive. Also taking out spawn because it's less commonly used in modern Rust code. They'll be moved into std/sync/comm modules.
  • brson: So, if you care about the fate of the prelude, voice your opinion!
  • aturon: Talking about the evolution of the prelude. One step is to put everything not in std::prelude directly but instead std::prelude::v1 so you can opt into newer ones. That way, if this is too conservative, we can add things back in later.
  • brson: As written, this does add a v1 module?
  • acrichto: Yes. Does not propose a versioning scheme, though. Just gives us some room to think about this in the future.
  • brson: Could be done either way, right? Later could add a v1 module that exports the same stuff that's in today?
  • acrichto: Then the v1 would be in scope for everyone...
  • brson: So there's not going to be one fascade prelude that reexports everything.
  • acrichto: Core will be on its own. std::prelude::v1::* will be injected by the compiler.
  • brson: Not a whole lot of feedback there right now...

Slice syntax ambiguity

rust-lang/rfcs#520

  • nrc: Change the slice syntax to use a range syntax embedded in array indexing (rather than a special syntax for slicing). Makes x..y first-class in rust. Problem is that if you have ..foo, then it's ambiguous with fixed-sized arrays and generating arrays with repeated expresions. At the workweek, we decided we would just not support them, since you can always stick a 0 at the beginning. There was an RFC, but people didn't like the asymmetry and that if it's not an integer range, (like days) you have to know what the start is (e.g., for days of week, is it SUnday or Monday?). So we suggested we could change the syntax for repeating and fixed-length arrays. Just wanted to see if there was support for doing this change. The current suggestion has parsing ambiguities. Considering changing the ,.. to for so you'd say [int for 42] instead of [int, ..42]. Vaguely similar to python and doesn't need any new keywords. What are feelings?
  • pcwalton: I never liked ,.. myself.
  • nmatsakis: Also could use # as an operator. [int # 42], [22 # 32]
  • pcwalton: I don't like #. Has there ever been a good language feature with #?
  • steveklabnik: Ruby comments!
  • brson: Does this cast doubt on the design of slices?
  • aturon: Not a lot of love for the fixed-length array syntax. Would be sad to block slices on that basis. I think we just need an alternative syntax.
  • nmatsakis: I don't think transitioning would be that painful.
  • brson: Decided not to use x beause it's context-sensitive?
  • nmatsakis: Looks the best. Does lead to some weird expressions:
[5 * x x 32] // weird
[(5 * x) x 32] // not so weird
  • brson: At least not ambiguous...
  • nrc: Only if you have a constant called x. Maybe not ambiguous, but weird.
  • brson: Seems like we are leaning towards changing the fixed-length array syntax. -nmatsakis: Agree, but seems like a lot of work...
  • acrichto: Changing .. to ...?
  • nmatsakis: Not sure how consistent that is with our choices in other contexts.
  • aturon: People seemed up for the for syntax? Seems unobjectionable.
  • nrc: I'm happy to let the debate play out more. I was more concerned about letting this run if the change was not going to be approved at all, rather than any particular syntax alternative.
  • pcwalton: I don't object to changing it.
  • brson: Problems with introducing a context-sensitive keyword? We could do anything we want if we do...
  • nmatsakis: The only keyword I'd want is x
  • brson: by?
  • pnkfelix: I think of that as the skip in a range.
  • brson: Let's just give the thumbs-up to keep iterating on it, then.
  • nrc: Will report into the RFC.
  • pnkfelix: With the schedule as it is, we need to decide sooner rather than later.
  • nmatsakis: Basically this week.
  • nrc: I'll strawman for and ask for a decision by end of week. I'll probably add myself as shepherd for this.

poisioning and mutexes

  • aturon: We plan to talk about this. Who wants to be there? Anybody have strong opinions?
  • acrichto: Me! Me!
  • nmatsakis: Me too.
  • pcwalton: I had some arguments. steveklabnik: poisoning people is mean, that's my opinion ;)
  • aturon: Just wanted to make sure stakeholders will be present (or at least invited).