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

Latest commit

 

History

History
128 lines (104 loc) · 9.73 KB

2014-12-09.md

File metadata and controls

128 lines (104 loc) · 9.73 KB
Raw

Agenda 2014-12-9

Attending

brson, pnkfelix, pcwalton, acrichto, huon, kmc, aturon, zwarich

Status

  • brson: combined installer
  • pnkfelix: drop lifetimes
  • aturon: IO/OS RFC, landing std::thread, implementing new Path, APIs
  • acrichto: hash stabilization, cargo bugs, mutex Result, channel Result

Action Items

Adjustments to RFC process

rust-lang/rfcs#506

  • brson: We're going to do RFC approvals asynchronously, as needed. This meeting will go back to an open format/discussion on topics. Hopefully this will allow for more diverse and meaningful conversation. See the above link for more details.

Box patterns

rust-lang/rfcs#462 and rust-lang/rfcs#469

  • zwarich: We had an RFC to make some changes to box patterns. As part of the linked discussion, the consensus emerged that for 1.0, we should just feature gate box patterns and deal with it all later.
  • zwarich: The main reason we're so concerned is that in the future we would like the compiler to not special case box. All functionality that box currently provides should be provided via a user-implemented library type.
  • zwarich: We have this figured out for the non-pattern matching parts of Box, but no one has fully thought out how to do it for patterns.
  • zwarich: The consensus is to feature gate for now, and deal with this in the future.
  • brson: So we keep box as the allocation syntax?
  • zwarich: Yes, this is just about patterns. pnkfelix has more to say about allocation, but they're orthogonal.
  • pnkfelix: I still need to write an RFC about box itself. Based on the data (with eddyb) from the workweek, it seems like there's a different strategy for box to make it more general purpose; I need to write that RFC. But I'd like to feature gate box patterns, since it's not yet clear how they fit in.
  • brson: zwarich, are there options/tradeoffs here?
  • zwarich: The question I want to raise is just the feature gate. If we don't gate, then we need to reconsider the design.
  • zwarich: Some question about the fallout; I don't have data. But the plan would be to land something there shortly after 1.0.
  • aturon: Would we lose any expressivity right now? Or just convenience?
  • zwarich: I can't think of a program you couldn't write without it.
  • acrichto: If you have a lot of nesting, box patterns are nice.
  • brson: So you said there was laregly consensus on this issue
  • zwarich: Yes, but it wasn't a very broad discussion.

Macros

rust-lang/rfcs#453

  • kmc: The summary from the ww is available via the RFC changelog.
  • kmc: We went back to prefixing the attributes with macro; I think I like the new names, which are consistent with macro_rules
  • kmc: Mostly, we were just nailing down final details.
  • kmc: Wildcard syntax would be just #[macro_use] with no ident list.
  • kmc: At the workweek, it really felt like we'd nailed down the final details and everyone was on board.
  • acrichto: One of the examples has a macro using another macro, which requires macro_use. Is it undefined if you don't do that, or only for cross-crate?
  • kmc: The helper macro is an implementation detail; you don't want the client to have to list it. It's an optional part of the proposal; could be dropped if we don't have time.
  • kmc: There are lots of more complex cases with helper macros that won't work properly. But this seemed like a useful feature.
  • nmatsakis: Not only cross-crate, but also any macro export situation where you don't export all the macros that you use.
  • kmc: Right now macro_escape gives you all the helpers by default. But if you can list them, then yes you have to deal with it. But I think within a crate it's not so bad, because the abstraction barrier isn't as high.
  • brson: What about future-proofing the grammar?
  • kmc: That hasn't been written up yet.
  • nmatsakis: We've started looking but don't have a concrete spec yet. But yes, we decided to split that into a distinct RFC.

Issue # in FIXME

rust-lang/rust#19546

  • nmatsakis: tidy used to fail if FIXME didn't ahve an issue number. I hated this at the time, but I came to like it -- now that tidy runs at the end, you can use it to leave reminders to yourself, while you pushed through compilation.
  • nmatsakis: But now I've discovered that you can get the same effect with // TODO
  • nmatsakis: I think nrc was annoyed by the FIXME change; I think he really wants issue numbers.
  • pnkfelix: Right now, there's FIXMEs where there's no place to log data about them. An issue gives you a place to post things about it.
  • nmatsakis: FIXMEs that describe actual bugs ought to have issue #s. There are a fair number where people feel compelled to say they weren't totally satisfied (often a waste of time). Things like "FIXME this is a hack".
  • nmatsakis: I think having issue #s is great, but we'd want to filter the FIXMEs that exist today to ones that are real bugs.
  • nmatsakis: It seems like a lot of busywork to go add issues for FIXMEs right now
  • pnkfelix: I agree. When we added issues before, we ended up with a lot of noise.
  • kmc: But it is a starting point.
  • pnkfelix: Also annoying for bug triage. [ some missed]
  • pcwalton: I strongly disagree. We need to have a clear option.
  • nmatsakis: Right now, I can write TODO and it will fail to compile unless I either convert to a plain FIXME or file an issue. Bottom line, this is not a priority right now.
  • kmc: One option would be to split FIXME into NB and convert them.

Servo issues

  • kmc: nmatsakis fixed the deeply nested Send problem
  • kmc: I think everything else is longstanding

Plans for box/placement new

  • nmatsakis: Felix has an RFC pending; I wanted to summarize what I see as the final decision.
  • nmatsakis: You can summarize the objections as: "this protocol would be cleaner if we had additional lang features"
  • nmatsakis: For context, the protocol is for a "placement new" that allocates, then computes a result into the slot
  • nmatsakis: There's a trait that the compiler interacts with that provides an unsafe pointer, and there's a finalize method that creates the final box.
  • nmatsakis: If there's an exception, there's a destructor on the partially initialized "agent"
  • nmatsakis: I do think that if we had more machinery, we could probably improve it -- but these are vague ideas that we're not sure will work. Lots of unresolved questions.
  • nmatsakis: So what this really comes down to is, would we like to have Box in the stable channel today with a protocol that might not be able to take advantage of new features? (It's been prototyped)
  • nmatsakis: Alternatively, we take out box and placement new and just call Box::new and Rc::new etc
  • pnkfelix: Can use a macro too box_in!(place, value) expands into an instance of the protocol (which is then defined in that associated crate e.g. up on crates.io).
  • nmatsakis: The tradeoff is, if we put in the protocol now, there will be a canonical way to box.
  • kmc: Can we evolve in a back-compat way? This is a trait, right? Maybe use default methods?
  • nmatsakis: Perhaps, but I don't know if we would.
  • kmc: Say we introduce &out or something that makes this cleaner; then future types could implement that version of the trait.
  • nmatsakis: I guess I have some doubts about how much nicer that gets in the end. You still have to deal with uninit memory. But in principle, yes.
  • kmc: The unsafe ptr solution fits with our current mental model.
  • aturon: How much work is involved?
  • pnkfelix: The work is pretty minor; it's mainly a question of whether we want to commit to the protocol.
  • nmatsakis: The other concern I have is, we'd talked about extending the protocol to support unsized types. That might make a lot of code nicer, and that would be a genuine extension to the protocol.
  • brson: My concern is that we've iterated on this for so long... it seems unlikely that this time at the last minute, we've gotten it totally right. There's a lot of risk.
  • nmatsakis: It's clearly a cuttable thing for 1.0. You lose some efficiency for large data structures. (I have no numbers)
  • brson: And we can fix that a few versions down the line.
  • kmc: There's the option of doing this in an external lib, but you'd have to do it through macros.
  • brson: At one point we were saying that all collections had to have support for allocators. Is this related?
  • nmatsakis: I think it's unrelated. We intend to add allocators backwards-compatibly.
  • nmatsakis: What I'm hearing now is: let's just cut the box keyword.
  • kmc: Need to make sure you can get the perf elsewhere
  • nmatsakis: We should be able to modify trans fairly easily to measure the perf impact
  • pnkfelix: I'll do the perf analysis [ some missed ]
  • pnkfelix: One potential problem with putting it into an external crate is that it is relying more on LLVM doing a "good job", more so than is strictly/hypothetically necessary if it is built into rustc
  • nmatsakis: The problem that led to the naive expansion (that then introduces aforementined reliance on LLVM) is lack of hygiene around unsafe, which forces you to isolate client-side expressions outside of unsafe blocks