- fott (brson)
- RFC for removing features (brson) rust-lang/rfcs#140
- lifetime elision (aturon) rust-lang/rfcs#141
- ref |x, y| (pcwalton) rust-lang/rfcs#151
- rpath (brson) rust-lang/rust#11747
- older RFCs (nrc) https://etherpad.mozilla.org/plSkp4vtwL
- matches! (acrichto) rust-lang/rust#14685
cmr, acrichto, aturon, bjz, pcwalton, steve, jclements, nrc, spernsteiner, brson, zwarch, jack, Luqman, lars, huon, azita, pnkfelix, dherman
- brson: ToStr, LLVM extract, intrinsics
- acrichto: cargo website, cargo native libs
- pcwalton: P-backcompat-lang issues
- nrc - DST traits - done, next - deep coercions?
- aturon: error propagation RFC, library roadmap, concurrency infrastructure
- acrichto: merge rust-lang/rfcs#140
- acrichto: merge rust-lang/rfcs#141
- brson: merge rust-lang/rfcs#151
- brson: merge rust-lang/rust#11747
- felix: work with huon on rust-lang/rfcs#16
- aturon: summarize rust-lang/rfcs#17
- acrichto: close rust-lang/rfcs#17
Sven Nilson has done a great deal of work to build up the Rust crate ecosystem, starting with the well-regarded rust-empty project that provides boilerplate build infrastructure and - crucially - integrates well with other tools like Cargo.
His Piston project is one of the most promising Rust projects, and it's one that integrates a number of crates, stressing Rust's tooling at just the right time: when we need to start learning how to support large-scale external projects.
Sven is a friend of the tree.
- [clapping]
- brson: Clarify the RFC process for removing features. Any objections?
- [crickets]
- acrichto: I will merge it.
- brson: We were right on the cusp of saying yes. Hopefully we can all agree that lifetime elision is awesome and we can go through with it. Any objections/clarifications?
- zwarich: Should we annotate lifetimes on unsafe code?
- acrichto: No, it goes to static.
- pcwalton: Well, actually, it goes to a lifetime that's at least as long as the function, which seems reasonable to me.
- zwarich: I'm willing to see how it goes.
- brson: pnkfelix, any comments on RFC 141?
- pnkfelix: I was thinking we could add a lint that would tell you about instances of the third rule, but that seems easy to add.
- nrc: Did we talk about how it works with UFCS?
- aturon: As long as we have a sensible idea of what a method is this can work. If not, we can revist it.
- nrc: I and others are somewhat uncomfortable with the third rule. But I think we're willing to just do it and see how it goes. Given that it seems to have relatively small impact how will we evaluate it?
- pcwalton: If it causes problems we'll know about it.
- nrc: [ ... ]
- aturon: We've already done that evaluation in two forms. The quantitative evaluation is in the RFC. The qualitative argument is that our traits are designed such that self has this special rule, and UFCS doesn't fundamenally change this.
- nrc: I agree with the evaluation you've done, mostly, but I'm wondering how we know if this is a success or not. If the second rule causes a lot of problem, we'll notice. But if the third rule causes problems, maybe we won't notice.
- aturon: I'm not sure what to say. The current rules are just not useful for output lifetimes. I feel like anything that makes them useful is a clear improvement. We've done an evaluation of all the places in std at least of all the places we annotate lifetimes. What point do you think we'll need to reevaluate that data?
- nrc: Even with the current lifetime elision rules, there are a number of cases where you don't need to write a lifetime but it's useful for debugging/error messages/whatever reason. I would say that for any lifetime elision rule it'd say 95% of the cases where you could use you, you don't, because it makes it hard to debug, then that's a rule we shouldn't have because that's a case where making the lifetime explicit is more clear. .... I'm worried that we have a rule that in a small way is bad, and encourages people to elide the wrong things.
- steve: My instinct is that if we don't notice there's a problem, that's a good indication that there's not actually a problem?
- brson: Nick, does determining the criteria for the effectiveness of this rule influence whether we do this or not? Can we do this offline? Do you mind going forward and seeing how it works out?
- nrc: No, I don't mind.
- brson: Any further discussion?
- acrichto: I'll merge it.
- pcwalton: There's a big thing about unboxed closures there with a lot of details and arguments for the specifics of those details, much of which is obsolete at this point. The one thing that isn't very controversial is making upvars by value and requiring a ref keyword before the first bar to get upvars by reference. Not a lot of discussion. bstrie is yasking for clarification on a syntax that doesn't exist yet, but not really relevant. I think we should merge this. This is going to be the largest breaking change, and is necessary to move forward getting us off boxed closures.
- brson: So all this does is make our current closures byval and add an escape hatch for byref?
- pcwalton: Yes.
- [...] The syntax should be forward-compatible with anything else we have for per-capture binding modes.
- zwarich: You're not opposed to having that syntax in the future? I remember someone gathering some numbers and being really strong for all byref or all byval.
- pcwalton: I don't think it will be necessary for 1.0.
- felix: The branch you made with everything byval is pretty strong argument that you can get by one way or another.
- pcwalton: Sure, byval is maximally expressive, the question is whether it's annoying.
- brson: Alright, I'll merge this.
- acrichto: Just a short thing. Addition to our prelude of macros. It seems nice, but it's adding a macro to every program forever.
- brson: I don't see examples on how you'd use it.
- jclements: I would have used this today...
- brson: And the motivation for doing this?
- steve: People are annoyed that match is getting noisey. The intention is this would simplify some of the uses of short matches.
- cmr: Sounds like this should go through an RFC?
- steve: Like we discussed last week, adding something to the prelude should have overwhelming evidence that it's widely useful.
- jclements: I don't think it belongs in the prelude, but [example of where this is super useful]
- brson: Clearly it solves some pain points, but I'm not sure how applicable it is.
- pcwalton: Especially now that we have loadable macros the bar for adding them to the prelude should be pretty high.
- acrichto: I'm in favor of punting on this.
- nrc: My feeling is that this is patching a hole in the language. It seems like the match does semantic pattern matching but you have to give it lots of options. For an if you give it one of the options but it does deep equality. Seems like the hole is in the language.
- cmr: Eridius is writing an RFC for this exact feature, if-let.
- zwarich: Yeah I feel like the Swift solution looks nicer here. If people are clamoring for this we should fix the language rather than adding a macro.
- pcwalton: Yeah, adding a macro doesn't please anyone. Minimalists don't like it because it adds a macro to the prelude, people who want the feature don't like it because a macro isn't nice to use.
- [ ... ]
- brson: Sounds like we're not going to merge this.
- brson: PR for disabling rpath entirely. Windows doesn't have it, linux distros don't like it, and its not very systemsy to be inserting things into every binary. Haven't discussed it though.
- acrichto: Every shared library won't know what to link against. If I build an executable, and then run it, it won't. We hide our shared libraries in a directory the system doesn't know about it. So if I download rustc and try to run it, it won't, because it won't know where its deps are. Build trees will also stop working, unless we enable rpath for builds. Additionally, installing the compiler to non-standard locations will stop working by default. A lot of uses of dynamic binaries will just stop working.
- brson: And the saving grace is that we static link by default.
- pcwalton: Additionally, this never worked on windows. All this stuff is broken on windows now.
- acrichto: [...]
- brson: I think you're painting a slightly worse picture of the installation case than it actually is. Anything we provide is going to continue to work.
- acrichto: The dynamic artefacts you link against are in a hidden directory.
- brson: Right, but by the magic of our build system, we have identical copies in the system dir.
- [...]
- acrichto: There are also bad things with rpaths. Distros will reject binaries that have rpaths. My recommendation is to remove rpaths by default.
- brson: Does anyone else have objections?
- lars: Is this going to break servo? We have some fairly ... creative ways of putting together binaries.
- brson: Ugh, this is going to destroy how servo works.
- [details]
- lars: Before you do this, can we go through what changes Servo needs to make?
- [more details]
- acrichto: Also, you can always pass a flag to rustc to get an rpath back.
- brson: Any final comments?
- brson: Ok, let's do it.
https://etherpad.mozilla.org/plSkp4vtwL
- nrc: Discussed this a while back, huon updated it. Do we want to merge it now?
- huon: There are still some edge cases. People should take another pass over the RFC, not discuss here.
- brson: Can someone work with huon on this?
- felix: I will.
- nrc: Discussed this previously, there's lots more discussion. Felix, an update?
- felix: There are some issues that the RFC itself doesn't address. There are some updates to the RFC that I'd like to see in the document before we merge it.
- [details]
- jclements: I have some more comments to add.
- brson: Do we feel motivated to do Iterable right now? Seems there are language features for it.
- pcwalton: It's backwards compatible.
- acrichto: It's nice to have, but seems we can do it later.
- aturon: The language feature is associated types. There are other things I want to do here. It's in my sights.
- brson: Aaron, will you summarize the changes needed before we can do this, and postpone the RFC.
- nrc: Lots of discussion, everyone seems to be in favor but hashing out the details. I assume we want to accept an RFC for unboxed closures. Is this the right one, and do we want to accept it now?
- pcwalton: Really need to wait for Niko on this. Especially since the stuff we're blocked on is another RFC that is already accepted. I see no reason to rush merging this.