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

Latest commit

 

History

History
260 lines (209 loc) · 12.6 KB

2014-09-09.md

File metadata and controls

260 lines (209 loc) · 12.6 KB
Raw

Agenda 2014-09-09

  • FnMut() sugar (pcwalton) rust-lang/rust#17041
  • associated types (pcwalton)
  • maximally minimal drop flag reform (pcwalton) rust-lang/rfcs#210
  • privacy amendments, RFC PR#200 (pcwalton)
  • efficient inheritance stuff - preparation for talking about this properly next week (nrc)
  • ast::P (pnkfelix) rust-lang/rust#13316

Attending

azita, spernsteiner, brson, aturon, pcwalton, nrc, acrichto, steveklabnik, felix, huon, zwarich, jack

Status

  • brson: win bots, aws bs, reviews, release process automation
  • pcwalton: P-backcompat-lang, associated types, RFC for capture inference
  • aturon: RFCs, collections, stabilization
  • acrichto: cargo registry
  • pnkfelix: allocator RFC, static drop
  • nrc: DST bugs, RFCs

Action Items

  • aturon: update associated items RFC with discussion below

FnMut() sugar

rust-lang/rust#17041

  • pcwalton: while we've been proceeding under impression that unboxed closure sugar looks like so:
// intended syntax
fn foo<F:FnMut(int, int) -> int>(f: F) {}

// approved syntax
fn foo<F:|&mut: int, int| -> int>(f: F) {}
          ^^^^
  • pcwalton: this was not in the RFC, so when I posted the patch people were surprised. it was an 'alternative' in the RFC
  • brson: intent was not to use the sugar syntax as a type syntax?
  • pcwalton: in the RFC I'm about to post, the 'approved syntax' would be used nowhere, self type is inferred.
  • brson: 'bar' syntax will exist?
  • pcwalton: yes, &mut to specify the self type won't exist
  • aturon: you are in the process of revising the RFC, can it just revise the syntax?
  • pcwalton: yeah, if we need it to go through the process again
  • aturon: worth pointing out that we have a strong motivation for the intended syntax, since we intend to have two different types of closure bodies
  • acrichto: in the RFC there was an alternative to make generic sugar for any tuple-like trait. seems not worth it.
  • pcwalton: agree

Associated types

  • rust-lang/rfcs#195

  • rust-lang/rust#16377

  • pcwalton: RFC hasn't been accepted and I want to land

  • aturon: there's a few details I think we need to finish up. Sounds like you had second thoughts about scope of assoc. items?

  • pcwalton: q is: in order to be consistent right now,

trait Foo {
    type T;
    fn bar() -> Foo::T;
    //          ^^^^^ note that this is required
}

trait Bar {
    fn foo();
    fn bar() {
        Bar::foo();
    //  ^^^^^ note that this is required
    }
}
  • pcwalton: above is what I implemented. to be consistent you have to prefix the trait when mentioning the assoc item inside the trait
  • pcwalton: strange that the scope rules would work differently for types than for other things
  • pcwalton: in favor of making it so everything in the trait is in scope without qualifications. make calling functions on self not require prefix
  • acrichto: could we be conservative by requiring the prefixing now, change later
  • pcwalton: not backwards compatible because name resolution
  • pcwalton: think it's not the end of the world to require it
  • brson: does 'use Bar::foo' work in this context
  • pcwalton: good q. conceivably
  • aturon: RFC did lay out several alternatives. for consistency can take 2 extreme positions: everything brought into scope, or nothing
  • aturon: proposal brought just types in to scope for two reasons: types you use a lot, have a convention that types are imported at top level
  • pcwalton: nervous about 'magic' scope
  • brson: 'magic' that certain types of assoc items are scoped differently?
  • pcwalton: yes
  • pcwalton: e.g. how does this interact with macro hygiene?
  • nrc: talk about 'use' makes a parallel with modules. if trait was a module you would not have to qualify anything, makes me think scoping should be consistent with modules.
  • pcwalton: can't be fully consistent, or else nothing outside would be imported. but yes, lots of similarities between traits/mods
  • felix: claim was made that requiring the Foo:: prefix is not that bad since it is expected to be "rare"; but this may not be true for type params, because many current things encoded as type params should be changed to associated types after they land.
  • pcwalton: we're talking about type parameters on traits which aren't that common
  • acrichto: example, Serialize trait has a bunch of assoc types
  • pcwalton: thinking about macros more, we shouldn't do this without consulting a macrologist
  • aturon: to be clear, this is an issue with the magic distinction. extreme positions are ok
  • pcwalton: yes, more comfortable with consistency. worried about complexity, macro hygiene. I believe the RFC as written breaks hygiene; algo depends on knowing whether names are in the type or value ns.
  • aturon: what does that mean for methods? what does it mean for a method to be in scope
  • pcwalton: can call via UFCS?
  • aturon: what does that mean?
trait Foo {
    fn foo(&self);
    fn bar(&self) {
        foo(self);
        baz();
    }
    fn baz() {}
}
  • aturon: are you saying you can call foo as above?
  • pcwalton: yes
  • aturon: how do people feel about this?
  • brson: can somebody import Foo::foo to use this syntax outside of the trait?
  • pcwalton: yes
  • aturon: I like this rule
  • pcwalton: wonder if it will break code
  • aturon: I think I'll update the RFC with these details
  • huon: some code has a method implementation that calls out to function with same name. will that break?
  • pcwalton: yes
  • huon: some of that in std. need to be updated
fn foo(f: &Foo) {}

trait Foo {
    fn foo(&self) { foo(self) }
}
  • huon: risk of silent infinite recursion. may be undetected
  • brson: hopefully we have a good test suite
  • pcwalton: I think we'll detect it because we'll do the transition in stages
  • aturon: just a concern for migration?
  • huon: yes

Inheritance

  • nrc: Need to bring this up next week. Please read RFCs. What can I do to make that happen?
  • zwarich: Have code examples implementing DOM side-by-side
  • brson: how many diff proposals?
  • nrc: 6. kimundi and eddyb talking about writing new one

  • efficient single inheritance rust-lang/rfcs#142

  • Virtual Structs (5) Stays as closely as possible to single inheritance in Java or C++. Touches only structs so does not unify structs and enums. That means we end up with two design choicesl (enums or virtual structs), where there probably shouldn't be. The scheme for defining virtual methods is used in this RFC.

  • Fat objects (9) Proposes using a pointer to a vtable+data and treating it as DST for representing objects. A very similar scheme is used in this RFC. RFC 9 does not actually propose a mechanism for supporting inheritance and efficient virtual methods, just a representation for objects (it suggests using Niko's earlier proposal for single inheritance by allowing struct inheritance and traits to extend structs). This RFC can be considered to take the object representation scheme from RFC 9 with a different mechanism for inheritance.

  • Extending enums (11) Proposes combining enums and structs in a similar, but not identical way to this RFC. Introduces impl ... as match and impl ... use ... to handle method dispatch.

  • Trait based inheritance (223) "This is largely based upon #9 and #91, but fleshed out to make an actual inheritance proposal.". I'm afraid I haven't spent enough time on this to give an accurate summary.

  • Kimundi and eddyb have promised an RFC for a possible solution using trait fields.

  • brson: probably take an entire meeting?
  • nrc: hope that maybe some of these can be rejected more easily
  • brson: and you want us to be primed before that?
  • aturon: are these all solving roughly the same problem? is there agreement on the problem?
  • nrc: I think there is agreement on the problem. constraints:
  • cheap field access from internal methods;
  • cheap dynamic dispatch of methods;
  • cheap downcasting;
  • thin pointers;
  • sharing of fields and methods between definitions;
  • safe, i.e., doesn't require a bunch of transmutes or other unsafe code to be usable.
  • nrc: each also solves other problems. they are general in different ways
  • felix: at least should give them champions
  • nrc: I can champion my own. 5 others
  • aturon: nrc, you will review regardless of who champions?
  • nrc: yes, but important I'm not the only one with an opinion
  • zwarich: I'll also read all, not sure I want to champion
  • felix: champion doesn't have to like the RFC, just represent it fairly

(assigning champions)

  • aturon: if you could summarize the highlights for us, that would be helpful
  • aturon: would be a good idea to post on discuss

AST Smart pointers

  • felix: eddyb revised AST smart pointers. For a major change like this, probably good to talk about benefits. What data do we need before deciding?
  • brson: remind us the motivation?
  • felix: currently using GC, but that's silly since you are going to throw it away again
  • pcwalton: false for our AST nodes because macro expansion
  • felix: because macro expansion throws away old nodes?
  • pcwalton: yes
  • brson: this uses arena and keeps all nodes around forever?
  • felix: my understanding, yes
  • huon: macro expansion destroys entire AST
  • felix: does it throw away the arena?
  • huon: I think this patch maps in place where possible, not sure it uses arena. may be using owned pointers or RC
  • pcwalton: feel like GC is the right choice, but should reuse nodes during macro expansion. GC after each round.

...

  • huon: other question of removing dependency on our GC
  • pcwalton: that i'm sympathetic to
  • brson: not clear what the mm strategy is in this patch. seems like none of us know
  • pcwalton: could start using raw pointers, after each macro expansion do a simple GC
  • brson: why are you attached to GC for this?
  • pcwalton: I think it will be fastest. avoids RC bumps; lets you throw away nodes, unlike arenas. GC pauses mitigated by lack of use after macro expansion.
  • huon: don't think using an owned pointer stops us from doing that. can move owned pointer out of old AST into new.
  • pcwalton: AST map creates multiple pointers
  • huon: AST map uses borrowed pointers
  • pcwalton: if that's the case that's amazing
  • huon: afaict P is now just an owned pointer
  • acrichto: in the last commit P is just a wrapper around Box
  • pcwalton: why the dep on arena?
  • spernsteiner: in current branch AST map is not borrowed pointers
  • huon: arena is used for AST map
  • huon: arena used for inline items
  • brson: felix, does that answer your q?
  • felix: no, doesn't describe the data we need; just that the design is sane
  • pcwalton: if it allows us to remove GC that's great. wouldn't gate landing on numbers
  • huon: one unsafe block in this patch, which is fewer. it is incorrect though - it relies on zeroing
  • brson: seems like it would be foolish to not get numbers
  • pcwalton: easy to do
  • felix: I'm happy to try

Drop reform

  • rust-lang/rfcs#210

  • pcwalton: RFC discussion is ongoing

  • pcwalton: can close the backcompat issue by implementing the rule about having identical drop obligations in branch arms

  • pcwalton: want to get the code-breaking part done

  • acrichto: felix, isn't it painful to do just that?

  • felix: no, I think pcwalton refers to something else

  • felix: in today rust, you can have match arms that take both by-move, by-ref, which is very hard to reason about

  • felix: RFC says match arms have to be consistent. I weakened that in the RFC because kballard wanted to be able to do it

  • pcwalton: how much code it breaks?

  • felix: very little

  • pcwalton: think we should make that change

  • felix: agree

  • brson: can you get a new RFC that just does that?

  • felix: yes

  • nrc: why can't we accept the entire RFC?

  • felix: there have been suggested ways to have dynamic drop without zeroing, e.g. keeping a bitmap in the stack frame

  • nrc: are we interested in this?

  • felix: some people thought that was going to be the solution

  • pcwalton: i'm torn. feel it doesn't matter that much

  • brson: affects ergonomics to use static drop

  • pcwalton: not really. static vs. dynamic only comes into play when it could drop in multiple places. think it rarely happens

  • brson: I thought the fact that it does happen was why the proposal was so nuanced

  • felix: some have claimed the proposal is too conservative

  • pcwalton: not making the claim that it's rare you conditionally drop things, but that it's rare you care when conditionally drop things