Skip to content

Latest commit

 

History

History
230 lines (191 loc) · 11.7 KB

2020-01-23.md

File metadata and controls

230 lines (191 loc) · 11.7 KB
Raw

T-Lang Meeting: Current meeting

Migrating back from the hackmd

Action items

  • niko to post summary comment on turbofish RFC and postpone - update: thought about it, didn't act yet because pondering - talked to varkor, will post comment soon
  • centril to comment on concerns re: inline asm rust-lang/rfcs#2836
    • should we have a follow-up meeting?
  • Centril to comment on floating point to integer casts can cause undefined behaviour #10184
  • Felix to comment on rust-lang/rust#68164
  • Centril to comment on #~~~~45600 and do PR too perhaps if he feels like it:)
  • Niko to announce design meeting schedule on Inside Rust blog
  • Centril to create issue to remove existing lint against nested unsafe blocks, add a allow-by-default lint encouraging them
  • Niko to write comment on RFC#2585 summarizing conversation from meeting

Upcoming design meetings

  • Feb 3 — Specialization infomercial (presented by Niko)
  • Feb 10 — Ralf + UnsafeCell bugs (#55005, #68206)
  • Feb 17 — (Niko is unavailable)
  • Feb 24 — ffi-unwind working group (we’d like to start some pre-discussion)

One thing not covered here that I want to do:

  • Plan out meetings for all hands
    • I want to do this more rapidly anyway, let’s discuss async in #t-lang a bit perhaps

Shepherded item updates

inline assembly (Amanieu, Josh)

  • lots happening here, expect 1st RFC show up soon
    • RFC to create project group in FCP
    • deprecate existing ASM, move to LLVM ASM (RFC 2843) opened
    • Initial inline assembly RFC (RFC 2850) opened

safe transmute (Ryan, Josh)

  • no updates.

const evaluation (ecstatic-morse)

ffi-unwind (BatmanAod)

"dyn Trait" stuff (nikomatsakis)

  • Relevant issue: rust-lang/rust#57893

  • Relevant PR: rust-lang/rust#66037

  • Still trying to get a crater run on latest proposal, had a few misstarts due to rebasing errors

  • What the PR implemented:

    • Making dyn Trait not dyn safe if:
      • there is a dyn overlapping impl and
      • the trait has associated non-functions
        • that do not have where Self: Sized (not implemented)

  • What we discussed:

    • If there is a dyn-overlapping impl:
      • and the trait is dyn safe
      • then the items in the impl must be default

  • To aid in reaching a final decision, want to have a write-up covering some of the alternatives

    • crater impact where possible
    • patterns that work or don’t work trait Foo { type Bar; }

    impl<T: ?Sized> Foo for T { type Bar = X; // This impl is allowed in the first version }

grammar (qmx)

  • no update

**never_type** (**!**) stabilization (nikomatsakis)

  • out of the blue Aaron1011 opened PR #68350

    • has an interesting plan that ties warnings to functions that produce ! but do not take a ! argument
      • if we default some type parameter X to !
      • and you have a function call in your code f(…) where:
        • return type of this function call includes X
        • the arguments to f are inhabited
    • alternatives:
      • make it a hard error — too complex and would require a very strong sense of false positives
      • deny by default to start — probably too strong
      • warn by default
        • but this might be silenced by allow-warnings
    • the concern: if they have #[allow(warnings)], they won’t see this
      • we could have an “unsilenceable warning” (or at least one with a minimum level)
      • but this would be a new thing
    • some question about how strong this lint should be, e.g., should it be silenceable?

    // functions that take fn foo(x: T) -> T { .. }

    // fn bar() -> T { } let x = bar();

    fn baz() -> Result<(), T> { Ok(()) } let x = baz();

    fn baz() -> fn() -> T { transmute() } baz()()

Shepherding proposals

None this week

Triage

P-high issues

Nominated PRs

Nominated issues

Nominated RFCs

  • RFC for unsafe blocks in unsafe fn #2585

    • Recent activity but generally positive sentiment from lang team members
    • Do you ever want a unsafe fn with no unsafe blocks in the body?
      • Yes: consider Vec::set_len, though unsafe fields might obviate this
      • If we had unsafe fields, we could probably give warnings if you have an unsafe fn with no unsafe blocks
    • Do we wish to merge?
    • What about #[unsafe] attribute as an alternative, opt-in syntax?
      • concern: unsafe is a keyword.
      • concern: “two ways to do it”
      • motivation?
        • avoiding breakage
        • unsafe keyword continues to be reserved for “(truly) here be dragons”
    • Rightward drift:
      • If you make a more narrow rewrite like let x = unsafe { foo() } that will help somewhat (we ought to be able to automate this, too)?
      • Maybe if you are writing a lot of smaller functions...
    • Niko: thoughts on potential edition interactions
      • side note: (re)consider unsafe vs trusted
      • I do like having the split between introduce and discharge keywords, like we have with async.await, so would in principle be in favour of trusted{} blocks, though who knows if it’s worth the churn — scottmcm
        • churn is indeed the main counterargument from my POV — nikomatsakis
    • Fighting rightward drift: unsafe fn foo() = unsafe { ... }; fn foo() = match some_expression_here { ... }; fn foo() = try { ... };

    fn foo(x: u8) -> u8 = x * 2 + 4;

    • Cluster of inter-related proposals here:
      • unsafe within unsafe fn body
      • fn body after =
        • fights rightward drift
      • unsafe fields
        • permits warning if unsafe is not used within fn body
    • Potential immediate steps:
      • Remove the lint that says “don’t add unsafe into the body”
        • maybe add a lint that warns if you do something unsafe in the body that is allow-by-default, so folks can opt-in
      • Consider whether to land the RFC
    • Compromise?
      • retool the RFC to a lint that warns by default?
      • this permits people to opt out in specific, FFI-like scenarios, but gives people a nudge
      • we can still have an automated transition, it could later become stronger etc
    • I’ll note that fn foo(x: u8) -> u8 { x * 2 + 4 } is already legal and fine and not materially longer, unlike in C# where the => removing the return and ; (and the get{} in properties) is more materially valuable — scottmcm
      • it’s not obvious to me that = x * 2 + 4 should be allowed, it might be something we limit to “the sorts of things that don’t require , in a match”, for example — nikomatsakis
    • Resolved:
      • Remove the existing lint
      • Add a allow-by-default lint for unsafe code in an unsafe fn without an unsafe function
      • Write a comment on #2585 that summarizes the conversation from meeting

  • Make the turbofish syntax redundant

  • target_feature 1.1

    • Centril wants someone to more convincingly say they’ll implement this.
      • Centril will ask T-compiler on Zulip.

rfcbot pending list

rfcbot pending list