aturon, pcwalton, zwarich, brson, nmatsakis, huon, acrichto, nrc
- acrichto merge rust-lang/rfcs#236
- brson merge rust-lang/rfcs#403
- aturon comment then merge rust-lang/rfcs#390
- aturon merge rust-lang/rfcs#401
- nrc merge rust-lang/rfcs#404
- acrichto merge rust-lang/rfcs#339
- aturon: Third try for setting conventions about when to use result/option.
- aturon: Rationalizes what we've been doing: no hard and fast rules. Some guidelines for distinguishing between contract violation vs "obstruction", the latter uses Result. Feedback largely positive.
- aturon: Issue to discuss: final point about whether you're ever allowed to have two variants, one that panics and one that returns Result. In general we are trying to avoid it. Currently there are some exceptions in standard library, channels and refcells.
- aturon: RFC proposes some standard naming conventions around these but it's unclear if we want to keep them around and no name has emerged as champion. RFC suggested
catchbut. - aturon: In interest of making progress and since these don't come up widely, I am fine with leaving language saying "don't do this" and not try to legislate a naming convention.
- acrichto: We can't forbid it entirely. But I like the option of just shelving the naming convention.
- aturon: For channels, feeling was that forcing you to type
recv().unwrap()was a bridge too far. RFC outlines some reasoning but it basically punts this to the stabilization process. - nmatsakis: +1
- acrichto: Estimate for how much code this affects?
- aturon: This RFC is giving up on clear-cut guidelines so in a way it doesn't force any changes.
- aturon: But it lets us mark various APIs "Stable" that are blocked on having final conventions.
acrichto will merge.
- acrichto: Overhauls build command support.
- acrichto: Few implications on compiler: moving linkage into a flag outside of source. As if you wrote it in the source. Big rustc change.
- acrichto: One somewhat controversial thing is that cargo will grow support for platform specific dependencies. But to use it you must specify the entire triple. But on unix I can't actually name all the triples. Kind of annoying to use. Divergent from our CFG syntax. Stems from my wish to not have cargo "looking at" using target triples. Suffices, need ability to drill down to a specific target, not maximally nice to use, but I'm ok with it for now.
- brson: is it possible to add wildcard support at some point?
- acrichto: Should be with a regex.
- brson: I feel ok about this
- nmatsakis: +1
brson will merge.
- RFC PR 390
- aturon: sfackler's proposal to change how enum variants are exported so that they appear under the type name rather than in the containing module. Lots of community support. Local team is split. Some are happy to see it land but don't want to commit resources. Others have some objections.
- aturon: sfackler actually has a POC working and has offered to transition libraries over to use it.
- aturon: has community support, but would like to hear from people who object on principle?
- pcwalton: I had objections but am somewhat resigned/convinced, though I am concerned about time. Reactions are either "meh" or "how could you not have done this before". In that case, we might as well just do it, though I am in the "meh" category myself.
- nrc: I am lukewarm. On the one hand, I think it can be useful, but my main worry is that it will not work well with nested enums, and I want those more than I want this. It makes a lot of sense when you are using enums in the way that you use C enums (just a bunch of differentiating things). But in Rust they tend to be more like replacements for objects and classes. Makes kind of less sense then.
- pcwalton: sfackler was allowing both? I think that's reasonable, schedule risk otherwise, and sometimes you want one and sometimes the other. Usualy response has been that you can
pub usethem, but that's worse, right? - aturon: that makes me want to clarify. RFC as originally written was staged so that for 1.0 we don't have to do anything but at later date you would get exports at both levels and there'd be a fallback mechanism so that we can gradually migrate away from exports at existing level.
- aturon: that was all about mitigating schedule risk. feeling right now is that poc and work that sfackler has been doing is only exporting at nested level, in keeping with general philosophy.
- nmatsakis: I didn't like the fallback. I kind of prefer one or the other. If we can't change in time I'd kind of rather not change. I was hoping to see examples of using
pub useto let existing code. To address nrc's point I think we can use out-of-line enum decls as nrc proposed at one point to allow for you to decide wheter you want the name to appear. - nrc: What is state of rfc at the moment? if we accepted now, would we be accepting a single mode with a transition period?
- aturon: that was the proposal but I don't think the rfc has been revised to reflect that
- nrc: I worry that there is a lack of clarify about just what is being accepted
- aturon: I would suggest we ask sfackler to rewrite the RFC to have the final target so that there is clarify
- nmatsakis: the big question is how much schedule risk we are taking on, it seems to depend on the robustness of the impl.
- acrichto: we could accept it but be aware that if it is not implemented we would roll it back
- pcwalton: pretty worried about deciding that we will block 1.0 on this (or giving impression) and accepting a half-baked impl that causes us a lot of schedule risk
- pcwalton: I'm fine with saying wanted not blocking, but if we accept it I really want it to be full and complete and not be in a state where we have to back it out half way
- nmatsakis: I don't know how to have that confidence
- aturon: Atomically transitioning the rust repo would be a start
- nmatsakis: that makes it hard to land but
- acrichto: I think sfackler can do it.
- nrc: This seems like the kind of change we would want experience coding with
- nrc: I'd be afraid of landing this the week before we go to 1.0
- nmatsakis: in this regard, landing the hybrid mode that works both ways might give us something so that we can evaluate the effect ourselves and still have option to remove it
- aturon: I do know that sfackler is chomping at the bit to get it done
- acrichto: in terms of actions, you are goin to say he should reword the RFC to describe the end goal and remove transition plan as an impl detail
- nmatsakis: can we accept based on that condition?
- nrc: I think so, presuming aturon gives the ok after reading it over
- nrc: in terms of an impl strategy?
- acrichto: I'd prefer an atomic change because I like a before/after picture but that's super hard to do
- nmatsakis: I can't decide if this mitigates risk but at least we know it'll handle the whole repo no action at this time.
- aturon: I don't think we want everything from this RFC
- aturon: Trying to complete story started by
try!macro. - aturon: Ergonomics of using result are improved but it is limited to jumping all the way out.
- aturon: This RFC is about taking that idea and allowing application of it at a finger grain.
- aturon: Having something that feels more like exception handling, but the control flow remains explicit.
- aturon: Some examples:
fn foo() {
try {
bar()?
}
}
- nmatsakis: One question is whether we should talk about this now -- will we do this before 1.0?
- aturon: main thing I would consider doing now is adding
?operator - acrichto: it is backwards compat to add though
- aturon: true, there is also a potential conflict between
trykeyword andtry!macro - nmatsakis/others: Let's table to discuss to unblock things
- nmatsakis: We've had a few iterations about using @ for both attributes and macros. But there have been several problems, so I've withdrawn that.
- nmatsakis: More generally, due to changes in our error conventions, I'm happy to keep ! for macros, and the community largely agrees.
- nmatsakis: We could potentially add @ for attributes later. sfackler was really interested in @id and then some token trees; may be opening an RFC for that. Seems fairly minor to carry out.
- nmatsakis: Unless somewhat wants to defend the older RFC, I think that proposal should die.
- nmatsakis: I would personally like to see @inline rather than #[inline], to match with other langs, but I don't feel very passionate about it. Similar to namespace variants, but a less scary change. Basically, would be happy to take a PR.
- pcwalton: Agreed.
- aturon: Me too.
- nrc: The coercions RFC has two pieces. First, it lays out/tweaks the rules for various casts, coercions, and so on. It adds a few coercions, e.g. from *mut to *const and removes a few that shouldn't be there, like converting from a fixed length array to an unsized slice by reference (just there for historic reasons). A few other tweaks, e.g. going from fn to closure types.
- nrc: The other part is laying out a system for custom coercions, mostly aimed at DST, so that you can implement a trait to allow your smart pointers to handle DST coercions. Then we can do Rc of unsized types just like we have Box of unsized types.
- nrc: In terms of priorities: there are a lot of tweaks, we could probably just do the back-incompat ones but it's easiest to just do them all.
- nrc: The DST coercions are not a backcompat hazards, but finished off the DST work. Should be high priority.
- aturon: I read the RFC in detail and think it looks good. We can separately triage the various portions (e.g. the DST coercions) in terms of 1.0 timeframe. But. But as a vision, I like it.
- nmatsakis: I'm happy to accept this now, but would prefer to not do the DST part now.
- acrichto: this is a small patch but it's blocking a number of people
- huon: does this give any way to force static linking?
- acrichto: no, we'll still have the case where you might pick up dynamic libraries
- huon: that'd be a nice future feature
- acrichto: generally I've found that is caused by linking to syntax accidentally
- acrichto: cargo helps because it does thinks statically by default
nrc will merge.
- acrichto: If you have a byte literal it generates a slice, this proposes making it a fixed-size array.
- acrichto: we removed a lot of stuff about fixed-size string literals.
- ... failed to take minutes, generally positive ...
acrichto will merge.
Failing destructors leak resources.
- nrc: what to do when failure occurs in a destructor
- nrc: atm we are just broken as far as I can see
- nrc: three options:
- nrc: (1) leave it broken, which leaks
- nrc: (2) panic in a dtor aborts
- nrc: (3) trying to do this propertly, where we carry on where we leave off
- nrc: Do we need to do this for 1.0?
- acrichto: (1) No one can possibly rely on the behavior we have today.
- acrichto: Most sensible thing to me is aborting if you panic in a dtor but detecting is expensive
- nmatsakis: Why would you call that sensible? Is there any language that does this?
- brson: Well we don't permit panicking during unwinding and any dtor should be ready to run during unwinding
- nmatsakis: Good point. I still think aborting the process is very heavy-handed.
- nrc: there is a cost to cleaning up
- nmatsakis: also a cost to detecting that you are in a dtor
- ... nobody took minutes, conclusion was that we would leave this unresolved for the time being ...