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

Latest commit

 

History

History
201 lines (158 loc) · 10.4 KB

2014-09-02.md

File metadata and controls

201 lines (158 loc) · 10.4 KB
Raw

Agenda 2014-09-02

Attending

azita, brson, acrichto, jack, nmatsakis, zwarich, aturon, steveklabnik, huon, pnkfelix, jbclements, nrc, pcwalton

Status

  • nmatsakis: generalized where clauses
  • brson: win64 bots, mac snap bots, windows bugs
  • acrichto: libgit2/openssl/libssh, cargo registry, servo cargo bugs
  • pnkfelix: allocator + static drop rfcs, ml + cufp presentations
  • aturon: collections, I/O, DST fallout, conventions fallout
  • pcwalton: landing parts of non-lexical borrows, associated types, higher-rank traits
  • nrc: DST raw pointers, mopping up DST bugs, remove trait cross borrows

Action Items

Friend of the Tree

Jorge Aparicio (japaric)

Jorge has made several high-impact contributions to the wider Rust community. He is the primary author of rustbyexample.com, and last week published "eulermark", a comparison of language performance on project Euler problems, which happily showed Rust performing quite well. As part of his benchmarking work he has ported the 'criterion' benchmarking framework to Rust.

Subslice patterns

rust-lang/rfcs#202

  • nrc: Decided earlier not to add more slice patterns, but we did want to future-proof the syntax. This is the RFC.

Int fallback

rust-lang/rfcs#212

  • niko: New RFC, limited discussion, but some good points. cmr's point: even with int fallback as proposed in RFC, something like the below fails to compile:

  • 1.method() still fails to compile

  • niko: otherwise mostly positive. some discussion about which type to default to. I still think it should be int, because it's the type people will expect. if int has the wrong size that's a different discussion.

  • felix: what about attribute to select the default type in a scope?

  • niko: backwards-compatible extension

  • felix: not if leaving out the attr is an error

  • niko: let's not do that. works against desire to have easy defaults.

  • steveklabnik: nobody has demonstrated a bug with fallback, afaik

Closures returning !

rust-lang/rust#16836

  • acrichto: PR adding closures that can return !. Basically already implemented in the compiler, this just adds the syntax.
  • felix: ! used to be a type - is it possible (?)
  • niko: ! was never part of type grammar
  • acrichto: though this is a language change, I think of it as a bug that it didn't exist
  • niko: agree
  • felix: would we infer !? if there are two paths, one that produces !, one that doesn't, want to make sure the inference makes sense
  • niko: seems to touch on the question of how we treat ! internally.
  • niko: I don't think we'll infer ! with this patch, because ! is a subtype of everything - doesn't add any type checking constraints.
  • acrichto: this patch only adds parsing. inference remains as-is today.
  • niko: looks like this PR needs more tests
  • brson: can you add comments about what tests you want?

Scoped attributes for checked arithmetic - glaebhoerl

rust-lang/rfcs#146

  • niko: RFC isn't clear about what changes to make. RFC seems to say overflow is undefined, to give room to change later.
  • jbc: scheme was ridiculed many years because order of evaluation of arguments was undefined (?)
  • pcwalton: it's not statically undefined, just unspecified
  • zwarich: one reason C won't remove support for signed magnitude is that emulating two's complement on float-only CPU's is very hard.
  • niko: think this boils down to ...
  • zwarich: this would take Rust somewhat away from other languages, where they distinguish "words" (just bits) and numbers. For numbers, options are:
    • undefined (C)
    • 2's complement (Rust today)
    • check but hopefully optimize away
    • Ada-style 'as-infinitely-ranged' semantics that allow for no overflow check if a mathematically correct result, but do not guarantee complete ordering of the resulting exception
  • nrc: adding scopes or a newtype are backwards compatible. the only thing backwards-incompatible is changing the defaults, and I think we're all convinced not to do that. any change here is backwards compatible and can be punted.
  • niko: I'd rather have defined behavior than undefined behavior in general.
  • niko: sense of the room seems to be reject. Anyone opposed?

ABI syntax

rust-lang/rfcs#156

  • nrc: Proposal is to dump quotes around extern ABI attributes so it looks like an identifier rather than a string.
  • acrichto: I don't understand the motivation of parameterizing over the ABI.
  • felix: The RFC is not just about changing syntax, it also lets you parameterize functions over the ABI.
  • niko: Not clear if it's being proposed or future work.
  • felix: Future work
  • niko: Possible under any syntax, though you'd need some keyword to introduce an "ABI" string
  • acrichto: If that's the motivation, then I don't agree.
  • niko: Strongest motivation I think is that the quote is ugly.
  • zwarich: Kind of strange that this is where we introduce types depending on values in the type system (?).
  • niko: You'd rather parameterize over ints?
  • niko: I think current syntax is fine. It's what C++ uses. Alternatives aren't especially compelling.

More index traits

rust-lang/rfcs#159

  • nrc: Add IndexGet/Set and change Index/IndexMut to take self by value. Don't remember why.
  • niko: Concern is that the way trait hierarchy is set up it doesn't work. Need to infer whether you want IndexGet or the others. This is kinda broken today so we need to fix it. You need to know ? before you pick which Index trait you are going to use. If nothing else we need to fix up the supertrait heirarchy. Otherwise not opposed to IndexGet: part of original plan but excluded to make our lives easier.
  • niko: The reason to change to by-value isn't clear.
  • aturon: Was'nt taking self by value but the index.
  • niko: Though IndexGet in this RFC is taking self by value.
  • acrichto: IndexGet is intended to be the moving out operation. Motivation for taking index by value is ... (?)
  • niko: What you lose by doing this is it's harder to use it with HashMap. If you take index by value you implement the trait like:
impl<'k, ...> Index<&'k K, ..> for HashMap<...> {
    fn 
}

let mut map = HashMap();
map[&key] // separate value for 'k
map[&key] // separate value for 'k

fn foo<'a,K,M:Index<&'a K>> {
    let key = ...;
    map[&key] // error: require a key with lifetime &'a
}

// higher-ranked trait bounds do enable this use case though:
fn foo<'a,K,M:<'a> Index<&'a K>>(...) {
    let key = ...;
    map[&key] // OK
  • niko: 'k doesn't appear anywhere. it's just free. Good for concrete hashmaps, but not generic. Each call to map[&key] gets seperate 'k. In a generic context though you have to 'lock in' the lifetime of the key.
  • niko: For closures we are going to end up with the ability to write higher-ranked trait bounds, which is complicated.
  • niko: I think the motivator for taking index by ref is to make it work with hashmaps without &, and to work in the generic case more cleanly, but you can't consume the key.
  • niko: We should iterate on it. I'll talk to sfackler.

matches!

rust-lang/rfcs#163

  • nrc: Similar to 'if let'. Tells you whether a pattern matches. Complementary to 'if let' since you can use it where you want a boolean expr. Doesn't replace 'if let' since it binds variables. Feedback very positive. Downside is that it adds more to prelude.
  • brson: Potential ergonomic issues with exhaustiveness checking and bad error messages?
  • niko: if you use with refutable patterns, yeah. The fact that it's a macro gives leeway to have bad errors.
  • niko: No opinion. Seems harmless. Popular.
  • brson: If it hasn't been in enough demand that people are using it out-of-tree, is it really useful enough to pull in-tree?
  • felix: SimonSapin is using it in servo
  • acrichto: I tend to agree that these types of requests may have undue weight because it's easy to +1 a PR.
  • niko: I've heard people ask for it a few times. But it's a 'low-simmering fire', especially since it's a one-line macro.
  • steveklabnik: Previously we've said 'overwhelming support' required to add to the prelude. Does this really meet that? You can add it as a cargo package.
  • niko: seems like we're not going to take it
  • nrc: What is 'overwhelming support'?
  • felix: We did take 'if let' without a lot of debate.
  • niko: 'if let' does have precedent.
  • jbc: needs a champion
  • brson: nrc is
  • nrc: I'm more concerned about policy of changing prelude
  • niko: bar for prelude and language aren't that different
  • acrichto: arguably prelude is the language
  • niko: would people want it if we didn't have to put it in the prelude? i.e., use std::util::matches;
  • nrc: I think so.

Feature gate advanced slice patterns

rust-lang/rfcs#164

  • brson: Too much complexity in slice patterns, this moves us toward fixing the problem.
  • brson: This just gates two specific features. There may be others.
  • niko: Yeah, just this doesn't alleviate my concerns.
  • nrc: Can we feature gate all slice patterns?
  • felix: All slice patterns, including single-element patterns?
  • niko: I guess, yes.
  • nrc: I also feel uncertain.
  • zwarich: Feel good about it theoretically for what's currently there, but I don't underestand the DST interaction, and believe we've got bad bugs.
  • niko: Hope they are not bugs people will rely on. I think feature-gating everything is overkill, just need to review the code before 1.0 and make sure we're all comfortable.
  • niko: why these two?
  • brson: implementation is immature
  • niko: that does seem like the role of feature gates
  • pnkfelix: also immature language design
  • niko: yes