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

Latest commit

 

History

History
179 lines (152 loc) · 11.1 KB

2014-07-22.md

File metadata and controls

179 lines (152 loc) · 11.1 KB

Agenda 7/22/2014

Attending

acrichto, steveklabnik, aturon, nmatsakis, larsberg, spernsteiner, luqman, zwarich, brson, pcwalton, pnkfelix, azita, erickt

Status

  • acrichto: cargo upload, cargo website, cargo new, cargo fun!
  • nmatsakis: #5277
  • pcwalton: Dedesugaring for, P-backcompat-lang
  • pnkfelix: non-zeroing drop

Action items

Friend of the tree

Jonas Hietala, aka @treeman, has been contributing a large amount of documentation examples recently for modules such as hashmap, treemap, priority_queue, collections, bigint, and vec. He has also additionally been fixing UI bugs in the compiler such as those related to format!

Jonas continues to add new examples/documentation every day, making documentation more approachable and understandable for all newcomers. Jonas truly is a friend of the tree!

Servo requirements

  • larsberg: dotdash just adopted llvm.lifetime.start/end intrinsics in Rust IR generation, so that LLVM has more accurate information about the lifetimes of stack objects. This will help reduce the stack space usage of Servo. yay!
  • larsberg: currently blocked on android cross-compiler snapshots
  • larsberg: 'make dist' doesn't include anything but the host target
  • brson: you have somebody lined up to do that?
  • larsberg: currently me. if it's trivial then I should be able to get it in the next couple of weeks
  • brson: Would you like help?
  • larsberg: Would love it if somebody has time.
  • brson: Just need an argument to 'make dist' that causes it to package the cross-compile targets as well? acrichto or I could do that quickly

RFC PR 123 - rename Share to Threadsafe

  • acrichto: some dissent to the word Threadsafe. Concurrent, Sync also suggested. I recommend Sync.
  • steveklabnik: all other kinds are short verbs, this is long adjective: Shared, Copy, Send, 'Threadsafe'?
  • acrichto: are you familiar with what Share does?
  • zwarich: bans interior mutability
  • acrichto: it just means that it's safe to share between threads. doesn't ban mutability. excludes Cell, RefCell.
  • acrichto: using 'shared reference' now for ampersand pointers
  • zwarch: convinced (ish)
  • nmatsakis: will merge

RFC PR 129 - asm! extension

(nobody took notes. waiting for more research)

RFC PR 130 - remove special treatment of Box by borrow checker

  • nmatsakis (missed)
  • nmatsakis: Remove special treatment, mostly affects examples like this:
fn example1(mut smaht: Box<Pair>) {
    let a = &mut smaht.a;
    let b = &mut smaht.b;
    ...
}
  • nmatsakis: if desugar this into calls to Deref methods you get into trouble because you end up calling the DerefMut method while you have an existing alias
fn example2(smaht: RefCell<Pair>) {
    let mut smaht = smaht.borrow_mut();
    let tmp1: &mut Pair = smaht.deref_mut(); // borrows `smaht`
    let a = &mut tmp1.a;
    let tmp2: &mut Pair = smaht.deref_mut(); // borrows `smaht` again!
    let b = &mut tmp2.b;
}
  • nmatsakis: plan to remove this. workaround by introducing temporary
fn example3(smaht: RefCell<Pair>) {
    let mut smaht: RefMut<Pair> = smaht.borrow_mut();
    let temp: &mut Pair = &mut *smaht;
    let a = &mut temp.a;
    let b = &mut temp.b;
}
  • nmatsakis: that's pretty much it. some code gets harder to write, but more consistent
  • brson: do you know offhand impact on current codebase?
  • pcwalton: think we should analyze that. concerned about growth of P-backcompat-lang
  • brson: niko, are there alternatives? current behavior is a hack, right?
  • nmatsakis: alternative is to have compiler automatically introduce the temporary
  • nmatsakis: could leave behavior and develop mechanism to support it across other ptr types
  • zwarich: is only special case behavior left being able to move out of Box?
  • nmatsakis: treatment of patterns and moving out. moving out is supportable i think, essentially a call to unwrap.
  • zwarich: i'm willing to implement this RFC
  • brson: ok, so cameron is going to do it, report back next week, then we'll decide

RFC PR 134

  • brson: Come back to this later?
  • pcwalton: Yes, we should come up with a different approach, but I'd like to see something like this happen.

RFC PR 136

  • brson: We have a lint that checks for banning publicly exposed private types. When we've talked about this in the past, we've been worried that detecting this correctly is hard to do in all cases.
  • nmatsakis: Yes, hard to clarify what guarantee you're getting. I feel like the lint is adequate.
  • acrichto: Legit use cases are in the comments, which is an interesting point.
  • brson: What's the motivation here? Seeing private items is weird in public signatures?
  • steveklabnik: Seem like it could be an error.
  • brson: Niko, you said you'd be happy to not do this, right?
  • pnkfelix: zwarich mentioned feature gating it.
  • zwarich: I claim that in some cases, this could be fixed by abstract types and modules. If we had them, we could get rid of this entirely, but now I'm not so sure if my suggestion is a great idea in the context of Rust. There are some places where people want to do this, but I'm not sure that this implementation covers all use cases.
  • nmatsakis: I'd prefer not to feature gate it - we have too many of them as is. In this case, let's make a decision. It's odd, but there's a lint for it.
  • brson: Any objections to saying no?
  • aturon: I'm uncomfortable with committing to this. Can we delay for another week so I can look at it?
  • acrichto: It's already a lint. In theory, the lint should be the same as what the RFC proposes. We could update the lint to test out the proposed behavior.
  • brson: Let's delay for a week.

RFC 143 - FromLiteral

  • brson: FromLiteral.
  • acrichto: I get the idea that making vectors & strings is hard today. But this specific design seems to only address strings and vectors, but we might like to extend to hashmaps, etc.
  • brson: Seems to overlap with several other ergonomic issues.
  • acrichto: I don't think we want this as-is.
  • steve: Is making these things easy to create going to result in their proliferation?
  • nmatsakis: But, when you need to make a vector, you need to make a vector...
  • pnkfelix: But, you can implement FromLiteral for any type, right?-
  • pcwalton: I don't want to do this now; we have too much else on our plate right now.
  • nmatsakis: Agreed.
  • steve: It's back-compat.
  • nmatsakis: Might want to add it with a fallback to the existing types, as it may impact type inference. Still, it's back-compat enough to get away with...
  • brson: Postpone.

Safe '&static mut'

  • pnkfelix: It seems like there are at least two sides on whether to do this or not. So, should this be an RFC?
  • brson: Background?
  • pnkfelix: Currently, a static mut can be borrowed (mutably or immutably), but either way you have to enclose the borrow in an unsafe block. The change here is to say that if the type of the static mut itself implements Share, you should be able to take an immutable reference without an unsafe block. The problem is that eridius pointed out that if you have code that is both reading and writing, now you've got a race condition, and only one of the two sides of this thing has an unsafe block. Today, without this feature, both sides have an unsafe block. The argument is that with this change, we have unsafe code that can't guard against a buggy bit of code in the safe world. My take is that there are lots of places where unsafe code requires privacy anyway to work in order to enforce any invariants.
  • nmatsakis: I agree with you. Unsafe establishes that we can't locally set conditions.
  • pcwalton: So, the problem is one unsafe block can affect the semantics of non-unsafe types? But you still can't cause a problem if there are no unsafe blocks at all.
  • nmatsakis: Another example of this is transmute, which can create illegal aliases.
  • pcwalton: Unsafe code can have non-local effects.
  • pnkfelix: I'm just trying to present the arguments being made in the comments on this issue. I believe they want us to require unsafe blocks to be isolated.
  • pcwalton: I can see where if you couldn't precisely define the behavior of the unsafe block, it would be a problem. Here, though, we can characterize the issues (i.e., no synchronization on writing to a static mut is racy).
  • nmatsakis: Yes, that's a responsibility of using this type.
  • pcwalton: Yes.
  • zwarich: was convinced by kballards argument, but field privacy is also part of safe code, and unsafe code requires field privacy for correctness. diff is once you have field privacy in safe code, another piece of safe code can't break ...
  • nmatsakis: not true. with Unsafe you have an analogous situation. Currently has public field you are not supposed to touch directly, except as an initializer. You have to use it properly.
  • zwarich: once field is private ... i guess you could return ref to it.
  • nmatsakis: could transmute to wrong type and escape.
  • zwarich: hard to distinguish this case from existing similar cases.
  • acrichto: q at hand is whether to put this through an RFC
  • nmatsakis: would be if not grandfathered in
  • acrichto: arguably not grandfathered in. not implemented for a long time
  • nmatsakis: have gone both ways in the past
  • pnkfelix: i'd like to understand the objection. haven't so far been able to understand the objection, not sure i'll get it in the RFC process
  • pcwalton: because there are objections doesn't mean we can't make decision
  • nmatsakis: pnkfelix, i thought you summarized well. kballard's pointing out that there are some odd interactions with unsafe, but they do exist in other places.
  • pnkfelix: worried that i didn't understand the objection. In particular it seems clear that one can construct examples of code where the unsafe blocks rely on invariants that are broken by buggy safe code, and it is the responsibility of the module writer to utilize privacy in order to establish (and enforce) the invariants via local reasoning about the module. So why do these cases not weaken (if not outright invalidate) the objections presented?
  • brson: how about taking it through RFC and seeing if anything is illuminated? (crickets)
  • nmatsakis: feel like we've done one for this...
  • aturon: niko, didn't you do some experiments here?
  • nmatsakis: (details)
  • nmatsakis: Alternative of adding 3 types of static constants seems worse than the problem we're trying to solve.
  • erickt: would this be easier with ctfe?
  • nmatsakis: initializer would go away
  • acrichto: would let us say' any static with Unsafe can't be in a 'static' slot'. ctfe is far away.
  • nmatsakis: can write up fast RFC