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

Latest commit

 

History

History
163 lines (125 loc) · 11.1 KB

2014-10-14.md

File metadata and controls

163 lines (125 loc) · 11.1 KB
Raw

Agenda 2014-10-14

Attending

pnkfelix, aturon, pcwalton, jack, zwarich, acrichto, nmatsakis, dherman, brson, nrc

Status

  • brson: std::char, release automation, hellgating RFC, combined install
  • acrichto: cargo linkage, cargo registry deployment, cargo registry fixups, cargo features
  • pcwalton: landing all Servo PRs, OIBIT, compiler perf improvements, Servo Samsung presentation slides, P-backcompat-lang
  • nmatsakis: integrate method dispatch with multi/conditional-dispatch etc
  • pnkfelix: PR for move fragments (for local drop flags); prototyping user-defined box
  • nrc - ufcs
  • aturon: implementing conventions, RFCs, finishing rtio removal, stabilization

Action Items

Yehuda Katz for weekly meeting

  • nmatsakis: I think that we ought to bring Yehuda Katz into the weekly meetings. He is a key early adopter of Rust and has been involved in advocating for Rust. Also of course implemented Cargo and is involved with the process of developing mio (along with many others). Has a lot of insight into language design in general and has been a helpful sounding board for me and others.

Queue size

  • acrichto: it's huge! take a look at your review queues and clean out old PRs if you've got some ones lying around

Servo

  • jack: cargo #601. need to turn on extra debugging features. jdm has been trying to do spidermonkey debugging.
  • acrichto: have some ideas for this, need to think about it more. maybe end of week
  • jack: Only other thing is Cargo #482, which would reduce our cycle time a lot, but doesn't actively block anything currently.

Object safety rules redux

  • rust-lang/rfcs#255

  • http://discuss.rust-lang.org/t/feedback-wanted-trait-objects-with-generic-self-methods/606

  • http://www.reddit.com/r/rust/comments/2ihu40/feedback_wanted_trait_objects_with_generic_or/

  • rust-lang/rust#17704

  • nrc: we approved this rfc, but there's a lot of worry that it's too rigid. e.g. iterators are not 'object-safe'. spliting Iterator into object-safe + non-object-safe might not be ideal. reddit thread and discuss thread looking for specific counter-examples: no concrete responses, just opinions.

  • aturon: I have concerns, and huon, and alex. main concern is complexity cost. Iterator and Reader/Writer have these problems. Reader/Writer are often used as trait objects but do contain some generics. In std, in examples we've seen we actually do end up with more flexibility if we split the traits. You could argue that by being forced to consider the question you do end up with better design, i.e. the change is doing it's job. Community feels it's an unnecessary restriction.

  • brson: 'community' meaning 'a handful of people'?

  • aturon: maybe a dozen comments on reddit. not many speaking in favor. decision isn't clear. being rigid here is simpler in some ways, complex in others.

  • nrc: imo these moves towards 'less flexibility' always involve some pushback. benefits here are subtle. volume of dissent is relatively small. conservative move as well: reversing the decision can be done backwards compatibly.

  • nmatsakis: re: 'better api's', these changes push toward a more object-friendly API. I feel conflicted. been discussing this for [years]. if we hadn't had this discussion we wouldn't have had this realization about Iterator (it isn't usable as objects). So in a very real sense the proposed change is doing its job.

  • aturon: apparent simplicity of current Iterator design is misleading since it isn't actually usable for trait objects. imo we should stick with the change as accepted, though that opinion is not based on much.

  • acrichto: I objected, but I understand better and am lukewarm

  • nrc: I'll rebase and try to land

Naming conventions

  • rust-lang/rfcs#344

  • rust-lang/rfcs#356

  • aturon: Two conventions RFCs. Not a lot of discussion on either. I'll highlight interesting points

  • aturon: in 344 significant change is to iterator type names. we've had several conventions. current convention is somewhat followed: noun /w prefix. guideline is vague, no way to determine which nouns, cases where convention isn't usable. e.g. Iterator trait adapters follow a different convention (the one i'm proposing) - name iterator the same as the method producing the trait: map() produces Map. Advantage: very mechanical naming; disadvantage: moving iterators become called IntoIter since into_iter is a method.

  • brson: naming for iterator methods are established already?

  • aturon: yes

  • aturon: we have convention for translating type names to method names, new conventions for naming types that only have syntax, no names. rest of the stuff is pretty minor. e.g. names for other minor common iterator patterns; conventions for lints - putting them into the sentence with the word 'allow' must work

  • acrichto: this also establishes new convention for traits in the prelude since they are never used.

  • brson: just for implementations on primitve types?

  • aturon: I think so.

  • nmatsakis: aren't there open q's about trait naming? we don't have to decide them now

  • aturon: in the old wiki guide there was a guide to prefer transitive verbs, nouns, adjectives, avoid suffixes. we don't follow it everywhere. this rfc proposes to nail down that convention, add rule that 'if trait with single method' you should consider just using that for the trait name. not a new convention, just codifying.

  • brson: and the other RFC (356)?

  • aturon: about stuttering module and type names. e.g. io exports IoResult and IoError (specializations). Results in stuttering: io::IoResult. Would be bad for prelude types, but not for the general case. This RFC says never to create stuttering prefixes. Client importers should prefer to import the io module instead of io::IoResult, can also import with renaming. No benefit in having the author do their own disambiguation.

  • brson: do we know of other places where we are doing this?

  • acrichto: TcpSocket and UdpSocket?

  • brson: we also reexport those from io. would those become renaming reexports?

  • aturon: yes

  • nmatsakis: with enums there are variants that are very common

[missed discussion about enum disambiguation]

  • pnkfelix: traits don't have this option to disambiguate based on module because they have to come into scope.

RFC Directory layout

rust-lang/rfcs#367

  • pnkfelix: last week we discussed the RFC directory layout, causes problems creating links: either link to PR or to the active document. we decided to get rid of active/complete directories, put a list of active RFC's in README. also stop assigning RFC numbers but use the PR number
  • brson: did you reassign old RFC numbers?
  • pnkfelix: yes. figured that would be more consistent. could grandfather the old ones though
  • acrichto: i'm fine reassigning. we're breaking all the links anyway
  • pnkfelix: also suggest we update the PR descriptions to point to the document
  • brson: I'll merge right now
  • nmatsakis: under this proposal when the RFC is first discussed you link to the PR, then the link changes after its merged. If the RFC is deleted it gets moved to a delete directory, that link still breaks.

Reflection

rust-lang/rfcs#379

  • acrichto: nrc has concerns
  • nrc: I do want this removed, but I also want a replacement for the {:?} logging in the compiler
  • pcwalton: I feel like 'repr' better
  • nmatsakis: want a trait to override this behavior
  • nrc: want repr and show. important to me to have a baseline that always works
  • pcwalton: not sure. have to try not to generate glue
  • nmatsakis: nrc how is that possible?
  • nrc: strawman: maybe a Reflect trait, compiler option, every type gets implementation. could be done like #[deriving(Show)] but always on.
  • nmatsakis: clearly not 1.0?
  • nrc: shouldn't block 1.0. not too much work
  • nmatsakis: current reflection interface is not something i can stand by. want it gone by 1.0
  • brson: can we hack rustc to always derive Show?
  • nmataskis: consider :? a bug. would rather remove them
  • pcwalton: agree
  • nrc: most output is useless, but there may be one bit of useful information
  • nmatsakis: why not just derive Show?
  • nrc: we could, just imagine it will be fair bit of work.
  • acrichto: less than implementing new reflection
  • nmatsakis: lots of design needed to do that
  • acrichto: nrc, can we jettison support for now replacing with deriving(Show)
  • pcwalton: have to do that or remove the logging

Const tweaks

rust-lang/rfcs#362

  • acrichto: minor tweaks learned from implementing the const/static split: forbid statics referencing other statics by value or inner addresses of other statics. Additionally forbid statics in patterns, only constants in patterns. Various other restrictions which became apparent once implemented.
  • nmatsakis: specifically in another static?
  • acrichto: statics in statics or statics in constants. statics in expressions are fine

Restrict \xXX to ascii

rust-lang/rfcs#326

  • pnkfelix: previously we've discussed changing the interpretation of \x. Currently it can take on values that are greater than an ascii codepoint, suggestion was to change so you no longer encode multiple bytes (or rather, that you would use the UTF-8 encoding when using \x, employing a series of \x's when necessary). This one though suggests least-common-denominator by restricting to ascii characters.

(agreement)

  • brson: char::escape_unicode needs to change