2015-01-06.md

Agenda 2015-01-06

• fate of box keyword for 1.0 alpha etc (nmatsakis)
• priorities this week (nrc)
• Servo - servo/servo#2853 (larsberg)

Attending

pnkfelix, acrichto, larsberg, aturon, huon, azita, brson, nmatsakis, nrc

Status

• aturon: Final pre-alpha stabilization, alpha announcement, path rollout
• acrichto: libs libs libs (hash/fmt), rollups rollups rollups, fixing ecosystem packages
• brson: release notes, feature staging
• nrc: mostly rebasing
• pnkfelix: sick; scopes, dtors, and box

Action Items

• pnkfelix - feature gate 'box', add Box::new

Friend of the tree

I nominate Jorge Aparicio (japaric) for Friend of the Tree (for the second time, no less!). japaric has done tremendous work porting the codebase to use the new language features that are now available. First, he converted APIs in the standard library to take full advantage of DST after it landed. Next, he converted APIs to use unboxed closures. Then, he converted a large portion of the libraries to use associated types. Finally, he removed boxed closures from the compiler entirely. He has also worked to roll out RFCs changing the overloaded operators and comparison traits, including both their definitions and their impact on the standard library. And this list excludes a number of smaller changes, like deprecating older syntax. The alpha release would not be where it is without him; Japaric is simply one of the best friends the tree has ever had.

servo update

• lars: Nothing that needs to come before alpha. acrichto and brson have landed some Cargo fixes (including $CARGO_HOME).
• lars: We are in the middle of an update to just before closure reform. We plan to immediately start an upgrade to alpha when that's ready.

Priorities

• nrc: Can we put off landing non-alpha blockers until Monday?
• aturon: We've done pretty well so far.
• acrichto: Anything for alpha is getting p=1 or higher. Anything else is in a rollup. It's just happening that everything is landing in the rollup...
• nrc: It's causing churn and forcing more rebasing of work.
• acrichto: I'm trying to rebase and merge all of the things myself (slice syntax was the outlier here). I'm trying to roll up the entire queue for things that have conflicts and rebase them all. Today, I'll prioritize getting through that.
• brson: The thing merging right now is an iOS fix, which should not have made it to the top of the queue, presumably.
• acrichto: I forgot to tag it rollup.
• nrc: Even stuff that's saving effort by putting it in the rollup, the few big things like Show reform and slices are touching 50% of the files in the tree so, even stuff that's totally unconnected vastly slows down rebasing on these and means you have to keep rebasing, then full make check, rebase again... the unrelated patches slows down people dramatically. And if it's stuff that isn't blocking alpha, can we just have a mega-rollup-burrito on Monday?
• pnkfelix: Even if we don't delay right now, we certainly need to stop landing patches like those at some point this week.
• acrichto: That's what the priorities should be for. It's possible that the really high-pri stuff is being rebased but something else hits the top of the queue. If so, you can talk to myself or brson and we'll disable bors for an hour until the important big stuff lands. The whole idea of the train model is that we can hopefully just keep working as usual. This process is a dry run of that. We might need to halt bors for an hour for rebases, but I don't think we need to do this.
• nrc: This is different, because we have a HARD backwards compatible deadline, so we actually need to not gate any of that work.
• brson: Yes, this is the first time we've done a feature-based release, which we've never done before.
• nmatsakis: Can we be specific? Things like the slice PR need to land. SHould we just shut off bors until that happens?
• nrc: Rebasing and making sure it passes make check is a half a day. Maybe shutting off bors won't help? Maybe rebase and rebase again at the end of the day? It's more that closing it early is hard...
• nmatsakis: We should coordinate the PR with any rollup attempts.
• nrc: Also coordinate with seanmonster about his Show reform. I'm worried that a lot of the slicing patch takes format!, which ends in an empty slice, replacing with as_slice or index_for_range, and it is going to completely conflict with his patch. Hopefully he can do it with a sed script.
• acrichto: If you want to rebase the slicing syntax, I can handle seanmonstar's, but hopefully we can land your slice syntax and then I'll handle rebasing his Show one and we'll prioritize those.
• brson: Is that OK? You've been asking for a tree close for like 3 days now :-)
• nrc: We could close the tree to try and land it tonight... that would be useful.
• brson: We should try to help you.
• nrc: I'll rebase, we close the tree, I'll rebase against what you have, and then we're good to go.
• acrichto: Once it's rebased, we'll put it p=10000 and put it on bors.
• nmatsakis: At least it'll hit Windows bugs faster if we do that.
• acrichto: I'll suspend bors; tell me when I can turn it back on.

LLVM updates

• nrc: Also, what's going on with LLVM updates?
• acrichto: All minor.
• nrc: They add significantly to build times.
• acrichto: Turn on ccache.
• nmatsakis: Still takes some time, but it helps.

Box

• nmatsakis: Need a box operator decision. Two questions: one syntactic, and one not. So, what is the syntax going to be? And, what is the protocol going to be? But the big thing to decide now is what strategy to take. One thing we could do right now is we could feature-gate box, the keyword, add Box::new as a public method, and maybe un-feature-gate it later in the beta period. Or after. Another thing is if we have some consensus on how it should look, we can try to put in something that would be forwards-compatible in alpha (meaning deleting the paren operator). So, do we want to feature gate box or make it forwards-compatible?
• pnkfelix: Or, do nothing, which I assume we don't want to do.
• nmatsakis: The concerning things today are that we have an ambiguous syntax today: box(place) expr
• nmatsakis: This has hit me several times before - try to box a tuple and it fails. Also, if you don't specify a place right now, it's hardcoded to Box, which is OK but not as good as it could be. It'd be much more useful if you could use it with any smart pointer type. But it's quite verbose if you try to use it with another type:

box(RC) expr // vs
Rc::new(expr)

• nmatsakis: We have an alternate design:

box expr    <-- uses inference to decide what sort of smart pointer
let x: Box<i64> = box expr;
let y: Rc<i64> = box expr;

in(place) expr 
in(vec.back()) expr
in(arena) expr

• nmatsakis: pnkfelix mocked it up via frontend rewrites. He and eddyb looked at the impact of using inference, and it seemed minimal. I guess that's the summary. Opinions?
• pnkfelix: Last time we talked about this, we floated the idea of feature gating box for alpha. I investigated (by expanding box to Box::new), but it didn't tell us much. Basically, if you use box heavily, the procedure call costs you the intermediate call, which is not a surprise. Just did some microbenchmarking that confirmed it. I did learn that pcwalton in Servo had identified hotspots where they had a copy on the stack that was getting moved and he deliberately got rid of the intermediary and put it on the argument on the box, which is a huge piece of data for the problem with going to Box::new globally, since it would remove the microoptimization. That's the main argument against only using Box::new. Counterargument is that Servo's always going to be using nightlies, so feature gates are fine for them.
• nmatsakis: So, we can't just drop box altogether. But it doesn't feel like a must-have for 1.0 alpha.
• acrichto: That sounded pretty convincing for having a feature gate for box. Box::new will be there, and we'll add something in the future to optimize it, but it's not there yet.
• brson: I also think this is the most expedient thing to do.
• nmatsakis: feature-gating box expression. Add Box::new, if it's not already there.
• nrc: Feature-gating all use of box, not just with parens?
• nmatsakis: Yes. Otherwise, it's not compatible with inference semantics. I've heard that it's not widely used outside our codebases. Ideally, we'd like to have it for 1.0, just maybe not for 1.0 alpha. So we could leave it in and say it's going to change slightly? Maybe just feature-gate the placed version.
• pnkfelix: And land the inference changes just after alpha, since it's "minimal."
• acrichto: If we feature-gate box expressions, do we need to do so for the patterns, too? Also, boxing a trait object means we can't express the new function, and it's basically required for unboxed closures.
• nmatsakis: Oh, yeah, that's a good point... so, if something is marked as unstable and you use it in alpha, you'll get a warning? That you can turn off?
• acrichto: Yes.
• nmatsakis: So I guess mark box unstable for alpha and then make the updates during the beta period.
• acrichto: Could add Box::new; the feature gate is just required if you're creating a trait object.
• aturon: How is this different from a feature gate?
• nmatsakis: I think I'm saying we should add a feature gate and it's like I/O in that we must do it before 1.0. So there should be a warning for alpha.
• aturon: Yes, that sounds good.
• brson: Probably need a fix for beta?
• nmatsakis: Agreed. Hopefully next week-ish.
• pnkfelix: What's the argument on trait objects? I thought you could make a concrete instance of the object, cast it to a trait, and use that?
• nmatsakis: Oh, yeah, that's right. I think it's that inference via eddyb's thing won't work with Box::new.
• acrichto: So, add a new function, add a feature gate, and then fix it.
• nmatsakis: Yes.
• pnkfelix: I may need to follow up with people because there's a LangItem for Box right now, so it might be a little tricky to land the function in the next 24 hours.

Recap: significant outstanding items before Friday?

• nmatsakis: Also, there's a milestone for alpha, but it's only tagged with my things right now. Box is on there!
• brson: So, box, show, slices, all of which are pretty big.
• acrichto: cmr's macro future-proofing. And his isize/usize thing.
• nmatsakis: Adds aliases and deprecates old names?
• aturon: He also needs a snapshot before he can get through. acrichto and I can coordinate... with nrc, too, on how to land these in the right order.
• nrc: At least cmr's is small at the moment. He's not doing the int->isize conversion?
• aturon: Nope; that will be a long, tedious conversion.
• acrichto: Couple of stabilization modules from aturon and I, but if that is the state for alpha, it's fine.
• brson: This sounds encouraging.
• nmatsakis: Rest are bugfixes and annoyances.
• brson: Going to try to have a build some time Thursday...
• pnkfelix: Should I try to get the destructor scope stuff in on this list?
• nmatsakis: Probably not going to happen. It's fairly complicated; needs detailed review; etc.
• acrichto: Is that backwards-incompatible?
• pnkfelix: Yes, some code will have to change, since declarations will have to be in a slightly different order.
• nmatsakis: It's a safety issue, though.
• pnkfelix: These are all situations where the thing you're guarding against is a destructor using data that's been destroyed. But all the cases are of a Vec failing to read the data correctly; HashMap doing similar; etc.
• nmatsakis: We may do better in the future.
• pnkfelix: You wouldn't see these soundness issues in the standard library's destructors, though.
• nmatsakis: That's not alpha. We should make a beta milestone and start putting things on it.
• pnkfelix: Not alpha-blocking, though if I can get it in...
• nmatsakis: Fine.
• acrichto: We may want a last RFC triage for backwards-incompatible changes.
• huon: Bugs, too, maybe?
• nmatsakis: Sounds like a good idea. Now?
• acrichto: Just a task for the alpha milestone.