#rust-lang

/

      • brson joined the channel
      • brson has quit
      • kimundi has quit
      • kimundi joined the channel
      • nagisa_ has quit
      • japaric has quit
      • Sascha joined the channel
      • Ericson2314 has quit
      • Ericson2314 joined the channel
      • niconii has quit
      • Tiziana joined the channel
      • Tiziana has quit
      • hash has quit
      • sfackler has quit
      • Tobba has quit
      • sfackler joined the channel
      • Tobba joined the channel
      • cjm has quit
      • cjm joined the channel
      • isHavvy joined the channel
      • hash joined the channel
      • hash has quit
      • hash joined the channel
      • hash has quit
      • nagisa_ joined the channel
      • Sascha has quit
      • Sascha joined the channel
      • arielby joined the channel
      • hash joined the channel
      • Soni joined the channel
      • hash has quit
      • Sascha has quit
      • [o__o] joined the channel
      • panitaliemom joined the channel
      • panitaliemom has quit
      • panicbit joined the channel
      • brson joined the channel
      • tm1 joined the channel
      • tm has quit
      • tm1 is now known as
      • Soni is now known as
      • niconii joined the channel
      • nmatsakis
        arielby: so yeah some random thoughts about unsafe code guidelines
      • first off, I was thinking some about Tootsie Pop model
      • I still find the idea of a "simple if inefficient" model to be a very appealing default
      • (regardless of the details)
      • but I was thinking that really we still have to think about
      • what if you DO want to opt-in to a model that allows much more detailed optimizations
      • how does *that* model work?
      • (so this model might e.g. be driven more by Rust types etc)
      • ok, that's just kind of an aside, though it does relate to what I really wanted to get at
      • which is that I feel like right now the unsafe guidelines discussion is all about the trees, not the forest
      • i.e., we're discussing lots of particular issues -- which is great! -- but I also want to think a bit about the high-level outlines of various approaches, so that we can say
      • "well, if we do approach X, that will make this question very easy, but appraoch Y is more subtle"
      • I'm not sure what's the best way to drive that forward -- I was wondering if we want to arrange some face-to-face discussion? maybe we can try to "tile the space" and explore what those approaches look like?
      • any thoughts on that?
      • arielby
        I don't know
      • ubsan and me had a "machine-style" approach in mind
      • nmatsakis
        ubsan: ^ this will interest yo :)
      • as a related aside, I've also been thinking about "permissions-oriented" vs "UB-oriented" models
      • I think they are sort of two sides of the same coin, but I think it's interesting to think both about
      • can we establish modular guidelines for checking code?
      • arielby
        what's permissions-oriented?
      • nmatsakis
        the rough intution is that instead of defining correctness of a program as over some dynamic trace
      • that you can reason more modularly
      • about what "permissions" you have from the safe interface of a fn
      • and check that your unsafe code adheres to those
      • this basically lets you decide if some unsafe code is "correct"
      • which seems to not really be a notion with a UB-based model
      • the simplest example would be `fn foo(x: *const u8) -> u8 { unsafe { *x } }`
      • this is not UB by itself
      • but it likely IS a permissions violation
      • arielby
        you mean safety proof vs. "machine safety"?
      • nmatsakis
        I find this a much more intuitive way to think about things; I'm not sure yet how it "maps". i.e., every permissions violation basically means "this is a fn that safe code could use to cause UB", in a sense
      • I'm not familiar with the term "machine safety"
      • but yes I thikn it is related to the distinction between
      • a "safety proof" vs a predicate applied to traces
      • I need to find some time to try to write out what I mean...
      • arielby
        machine safety = safety in a "machine model"
      • trace-wise lack-of-UB
      • nmatsakis
        ok
      • then roughly yes
      • that said, time for meeting :)
      • compiler meeting, I mean
      • arielby
        vidyo or IRC?
      • frehberg joined the channel
      • frehberg
        Manishearth: Hi, thanks for the help some weeks ago, finally crate 'releasetag' has been published :)
      • jseyfried joined the channel
      • playbot has quit
      • playbot joined the channel
      • nrc
        nmatsakis: your sound off?
      • eddyb
        I missed compiler team and now vidyo is segfaulting. what a great way to start the day
      • mre joined the channel
      • aturon
        eddyb: :(
      • pnkfelix
        argh i kep getting kicked off my *own* wifi!
      • mre has quit
      • nmatsakis: in the Swift-inspired hypothetical syntax here https://internals.rust-lang.org/t/pre-rfc-named... ...
      • nmatsakis
        nrc: ps one thing I was wondering; it seems like we don't necessarily need *anonymous* structs, so much as the ability to omit the name from a struct literal, for your "struct-based named parameter" concept to work
      • pnkfelix
        nmatsakis: ... is it as simple as just a pair of idents is how you opt into using a keyword at the declaration site? Amazingly I don't see any obvious parsing ambiguities with that appoach, am I dense?
      • nmatsakis
        nrc: e.g. you could imagine that `{ foo: ... }` would be legal if (via the expected type) we could deduce the struct name (note though that there remain parsing difficulties)
      • nrc
        perhaps
      • pnkfelix
        nmatsakis: (by "pair of idents" I mean `fn move(by increment: u32) { ... }`
      • nmatsakis
        pnkfelix: probablt ident + binding
      • pnkfelix: but yeah
      • er, ident + pattern
      • pnkfelix
        nmatsakis: oh right, `ident pat`, right?
      • nrc
        seems like that would add some friction to declaring such functions
      • pnkfelix
        nmatsakis: the more I think about that, the more I like it
      • nrc
        we already have @ syntax for ident pat
      • arielby
        nmatsakis: I've long wanted
      • nmatsakis
        nrc: different meaning, of course :)
      • arielby
        `_ { x: A, y: B }`
      • nrc
        yeah, but still
      • pnkfelix
        nrc: yeah I'm not quite sure why you raise `ident @ pat`
      • nmatsakis
        arielby: that would solve the parsing problems;
      • nrc is still not persuaded by the motivation for the Swift approach
      • nrc
        pnkfelix: just brainstorming syntax
      • nmatsakis
        just a bit unergonomic if it's meant to replace named arguments
      • nrc: well, it neatly addresses the problem that we don't actually *have* named arguments in rust
      • if nothing else :)
      • pnkfelix
        nrc: although ... I guess I do see it if you twist your mind to seeing it as `binding @ variant-name`
      • nrc: but then would callsites look like `move(argument @ keyword)` ?
      • nrc: I need to finish reading the thread, maybe someone already said all this
      • nrc
        I guess it might parse?
      • nmatsakis
        wait what
      • why would we use `@` ?
      • just to make it uglier?
      • oh, I guess to address the parsing ambiguity :)
      • pnkfelix
        nmatsakis: I was trying to understand nrc's earlier point
      • nmatsakis: and I think the idea, or part of it, is that we already have a syntax for saying "binding this thing when you match against this constraint"
      • nmatsakis
        I guess I see it as very different since
      • the swift name does not create a binding
      • arielby has quit
      • pnkfelix
        nmatsakis: it decouples the external keyword from the internal binding, right?
      • nmatsakis: `internal-name @ external-keyword` was what I was seeing as the same thing
      • "external keyword" is "external" in the sense that it becomes part of your public API
      • pnkfelix is really just trying to shuffle his way towards unifying function arguments with enums
      • in terms of syntax in an absolute sense I think Swift's approach is nicer for code readability when you have code that actually compiles
      • but I'm betting that we'll have much nicer parser errors if we do someting like `arg @ keyword`
      • nmatsakis: (oh did someone actually present a parsing ambiguity with the swift `by increment: usize` approach? I though you didn't know of any up above...)
      • nmatsakis
        pnkfelix: not that i know of, the ambiguity is with type ascription
      • foo(x: 3)
      • pnkfelix
        nmatsakis: okay sure, that's when you use colon to indicate the keyword, okay
      • nmatsakis
        er, foo(by: 3) I guess, per your eample
      • yeah, the ambig is at the call site
      • pnkfelix
        nmatsakis: I thought it was `foo(by 3)` ?
      • nmatsakis
        ah, well, that's not been proposed, but might actually work :)
      • pnkfelix
        nmatsakis: I bet that's what I misunderstood
      • nmatsakis: aha, yes I misread your post and missed the colon in there
      • nmatsakis
        man but that will restrict our future space of keywords