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

Latest commit

 

History

History
133 lines (116 loc) · 10.5 KB

2015-03-10.md

File metadata and controls

133 lines (116 loc) · 10.5 KB

Agenda 2015-03-10

Attending

  • pcwalton, nmatsakis, nrc, steveklabnik, kmc, huon, aturon, acrichto

const fns

rust-lang/rfcs#911

  • nmatsakis: Summary: eddyb opened an RFC, which allows you to write const fns with a very limited form. It's evaluable at compile time. The form is basically whatever you can put in a constant today -- basically, just one expression in the body (there are maybe some exceptions)
  • nmatsakis: The main goal here isn't to enable CTFE, but rather to enable abstraction. Right now, we have to make certain fields public to allow you to write a const initializer. Examples, UnsafeCell. Right now, we use macros and stability to work around the abstraction problems.
  • nmatsakis: The major pro is that it solves this problem in a more elegant way. The con is that it's a pretty big change to try to land now, if we want to use it to stabilize these things now.
  • nrc: Is there an implementation?
  • nmatsakis: Yes. I'm not sure whether it's been rebased -- I haven't looked closely, but I suspect it's good.
  • nrc: Is this part of getting rid of static mut, does this help?
  • nmatsakis: I think it's orthogonal.
  • acrichto: It will pave the way, but doesn't get all the way there.
  • nmatsakis: Because you can't make a RefCell in a constant right now?
  • acrichto: Yes.
  • acrichto: I agree that this is very good, and I like the stress on adding the abstraction facility. I do share the worry about how this integrates with CTFE and other future features.
  • aturon: I don't feel a lot of pressure to stabilize all this for 1.0, the examples in std can stay unstable for now. But I think it's fine to land under a gate for now, and gain some experience.
  • pcwalton: I was a detractor before, but I'm somewhat swayed by these arguments. That said, I do think we should consider interactions with future CTFE. I don't have concrete concerns there. But I'm generally wary of doing design in baby steps, without seeing the full picture.
  • nmatsakis: In the past we've talked about CTFE via syntax extensions. I don't know if that's still a possibility. That could sidestep some of the limitations of D, for example.
  • pcwalton: I almost feel like, if we have const fn, we have committed to CTFE in some form.
  • nmatsakis: Maybe. Like macro rules, though, there could be advantages for having a simple, portable system separately from a maximally-expressive one.
  • nmatsakis: One advantage of const fn is that you can apply these fns dynamically as well as statically.
  • pcwalton: Will we want const if and so on? Unclear.
  • nmatsakis: The abstraction thing does seem like a legitimate need.
  • acrichto: But could it be solved more simply?
  • nmatsakis: I don't know of any alternatives; this always seemed like the obvious way to do it.
  • pcwalton: I've been against a full interpreter in the language (like D), but maybe that's the road we're on.
  • nmatsakis: I feel like it's harder than D.
  • pcwalton: Definitely. We have type classes! We have to ensure type safety of generics.
  • nmatsakis: Also the compiler doesn't understand memory allocation, boxing, etc (or it won't in the future). So it'll be much harder to interpret a reasonable subset of Rust
  • pcwalton: That alone might form a natural boundary to how far we want to go.
  • nmatsakis: There may be workarounds, I'm not sure.
  • pcwalton: The nice thing is that it's fairly easy to spec -- you can just say it's the full language.
  • nmatsakis: Minus the libraries.
  • pcwalton: That's the sleight of hand we'd be pulling. Since so much in Rust is in the library...
  • pcwalton: It avoids having to carve out ad hoc subsets of the language.
  • aturon: Before 1.0 we've been able to experiment with features, get experience, change them, rip them out, etc. It'd be nice to keep doing that after 1.0, with feature gates and stability. Can we "try" this out in a gated form but not commit?
  • nrc: [missed]
  • nmatsakis: privacy hygiene would help
  • pcwalton: I feel nervous about adding complexity to work around a bug in the macro system (privacy hygiene)
  • nmatsakis: Or are macros working around a language limitation
  • aturon: In a sense, macros are a language design smell :)
  • nrc: On the other hand, this kind of compile-time computation is what macros are for. Given that we want privacy hygiene eventually...
  • nmatsakis: Yes, that's one reason for macros, but there are lots of other use-cases around e.g. saving repetition.
  • nmatsakis: But, privacy hygiene is the major competitor.
  • acrichto: If we had implementations of both privacy hygiene and const fn, it seems like we'd take hygiene
  • aturon: False choice!
  • nmatsakis: I would want both.
  • acrichto: We probably do want both in the long run.
  • nmatsakis: We'd be saying, if you have a type that's reasonable to constant-evaluate, we'd have a convention to use macros for the constructor instead. (If we don't have const fns)
  • acrichto: I don't think this will get rid of any macros in std
  • nmatsakis: I just think that's a matter of where we're using macros -- we could be using them for UnsafeCell
  • nmatsakis: So conlusions:
  • Privacy hygiene is the main alternative
  • We probably wouldn't want to stabilize this too quickly
  • Need to think through CTFE/syntax extensions here

Wiki

  • nrc: Steve nixed the Wiki the other day. I wanted to check in about this.
  • steveklabnik: This was a bit of an executive decision on my part. We've had a long-running process to move things from wiki to docs. But there are some licensing issues.
  • steveklabnik: After having moved most things to the docs, I wanted to go by-need.
  • nmatsakis: Where will this stuff live now?
  • steveklabnik: Before, things went to the wiki to die. I've been putting pages in various places, depending.
  • nrc: The thing that worries me is that there's a lot of useful stuff for hacking on Rust, and there's no place for that to go. That's what I found most useful.
  • steve: Could that be in markdown files in the main repo?
  • nrc: But it's hard to find. For example, the wiki had a great page for testing. That stuff is in the repo, but scattered and hard to find.
  • nmatsakis: Could just have a subdirectory, or another repo
  • steveklabnik: In repo is probably best.
  • nrc: docs dir seems fine
  • acrichto: There is a huge cycle time to make changes. But if you're working offline, you have it all available. Also helps keep it in sync.
  • nrc: Discoverability is important too
  • aturon: Also one reason we nixed the wiki was lack of a review process; so why not integrate?
  • nmatsakis: Let's do it
  • acrichto: Is there a licensing problem with just dumping the existing wiki into the current repo?
  • steveklabnik: We can move the wiki, but can't extract the files. brson talked to moz legal about this, may have more insight about the issues here
  • nrc: Is there stuff beyond rustc docs that's useful?
  • steveklabnik: The OS dev page, for example
  • acrichto: The more flavorful OSes have nice docs
  • nmatsakis: That can live in the repo though. Easier to keep in sync with Makefile then
  • nrc: Ok, let's try it.

Hyphens in crate names

rust-lang/rfcs#940

  • acrichto: There's a PR to deny hyphens in crate names. This has to do with the fact that many repos have hyphens, but you have to put it in quotes. People do feel like hyphens are prettier, but that doesn't outweigh the burden with quotes.
  • acrichto: You're forcing everyone in the world to use quotes if you use hyphens.
  • acrichto: There's a lot of support for this. It will need a migration path.
  • nmatsakis: Are you talking about dropping quotes from the crate import system?
  • acrichto: It doesn't say so, but you might want to remove them
  • nmatsakis: But what if you have a space in the file or whatever?
  • acrichto: There are already checks that rule that out.
  • acrichto: The #1 dep in crates.io has a dash in it.
  • aturon: Keep in mind, part of the issue is that hypens are the convention for e.g. github. Can we just allow them without quotes?
  • nmatsakis: No, but we could do some translation
  • acrichto: Or fuzzy matching. There hasn't been a lot of support for that alternative, but maybe we can explore it a bit more.
  • aturon: This has been a constant issue since at least crates.io came out -- seems like we should probably do something.
  • steveklabnik: This seems like a lot of noise over a very minor point -- trying to allow for hyphens. Why not just ask people to follow our convention here?
  • nrc: Because the rest of the world follows a different convention, so there's tension here.
  • nmatsakis: Also, we have a lot of packages with dashes, so at this point there's effort to change it.

Statement-ize looping forms

rust-lang/rfcs#955

  • nmatsakis: This is an RFC from Felix. Someone had proposed that loops not always have unit returns (which is not very useful). In particular, while/for would have an optional return value, and you could pass a value via break.
  • nmatsakis: If you did that uniformly across all loops, and break; was shorthand for break (), you'd be in a backwards-incompat position.
  • nmatsakis: To future-proof, you could require that if a loop appears in tail position in a block, it has to have a semicolon. In all other cases, the current rules already throw away the result.
  • nmatsakis: Sorry -- the RFC says to only accept loops at statement level, and give an error otherwise.
  • nmatsakis: I don't think we should do this, for a few reasons. For one, this would require semicolons at the end of e.g. while loops in tail position. Wouldn't feel like C. Kind of a non-starter IMO
  • nmatsakis: Second, you can add this feature backwards-compatibly with a somewhat different design.
  • nmatsakis: Finally, there's a lot of overlap with the proposed feature and things like iterators.
  • acrichto: The idea of break taking an expression seems pretty alien to me!
  • nmatsakis: Yes, though it is neat.
  • nrc: Why do you need a semicolon? If it's statementized...
  • nmatsakis: There are contexts in which you would use the value of this while loop and if its type changed, we would break some code.
  • nmatsakis: So suppose you have a fn that returns i32 and it just contains a while loop, you get a type error because the result of the loop is (). But if the return value changed to produce an Option, you would get type errors in different cases.
  • nrc: I do agree that requiring semicolons seems bad.
  • huon: There are various ways we could change the original RFC to add it safely later.