# Backlog Bonanza 2022-01-19

[GitHub query](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AC-tracking-issue+label%3AT-lang)

## What are we DOING?

* Take things that have been unstable for a while and "disposition them".
* Goal: Everything that is nightly only has one or more of the following labels, indicating the blocker(s) to stabilizing it:
* S-tracking-ready-to-stabilize: Needs a stabilization PR (good to go :train:)
* S-tracking-needs-to-bake: Needs time to bake (set a date? other criteria?)
* S-tracking-impl-incomplete: Not code complete or blocking bugs
* S-tracking-unimplemented: Implementation not begun
* S-tracking-design-concerns: Blocking design concerns
* This might be "doesn't quite seem to deliver value we hoped for" or "something doesn't feel right"
* S-tracking-perma-unstable
* Internal implementation detail of rustc, stdlib
* S-tracking-needs-investigation

Attendance: Josh, Niko, Scott, Mark, dbarsky

## Tracking issue for allowing overlapping implementations for marker trait #29864

* Also the tracking issue for `#[marker]` annotation itself
* which was added later in the design
* Summary by Ryan [here](https://github.com/rust-lang/rust/issues/29864#issuecomment-676332502)
* The proposed "unsoundness" is really about sidestepping the orphan rule
* [lcnr comments](https://github.com/rust-lang/rust/issues/29864#issuecomment-977146324)
* Niko: I don't think it is unsound as is (assuming it only applies to overlap rule)
* you would have to have something like `impl<T: Foo> Marker for T` in a downstream crate, which is disallowed by the orphan rule
* the example as given by lcnr doesn't require marker
* Niko to summarize
* Things to follow up on:
* Clarify why cannot be extended to orphan rule
* Documentation of what it does and doesn't do, including this
* Can we make `Copy` a marker trait?
* Look at all traits in libstd/libcore that have no methods
* Question: Is it a breaking change to add `#[marker]`?
* Feels like it *shouldn't* be, gives capabilities but doesn't take them away
* Review the unpin situation
* Need review by trait/type experts, or better understanding of our type/trait system

#![feature(marker_trait_attr)]
// #[marker] <-- not actually necessary for this example
pub trait Marker {}

pub struct B;

trait NotMarker {
    type Assoc;
}

impl NotMarker for B {
    type Assoc = usize;
}

impl<T: Marker> NotMarker for T {
    type Assoc = Box<String>;
}

## Restrict use of constants in patterns (RFC 1445) #31434

* Intersects valtrees and other things

struct Foo;
const F: Foo = Foo;

let f: Foo;

// f == F --> Compilation error, doesn't impl PartialEq
match f {
    F => /* ok */,
}

* Restrictions that were meant from doing this unless you derived PartialEq and Eq
* Core question: is matching on a constant the same as

// Are these the same?
if F == f { }
if let F = f { }

* Initial check had to be patched a few times, along the way a private trait `StructuralEq` was added
* Had a discussion about semantic equality
* Probably at the point of "needs a design meeting about semantic equality"
* nikomatsakis: I was one of the holdouts that felt that `F == f` and `if let F = f`
* joshtriplett: do we ever intend to stabilize StructuralEq?
* scottmcm: I think some kind of unsafe impl might be the story ever
* nikomatsakis: that's equality the question (or one of them) I think we need to answer in having a meeting about structural equality
* joshtriplett: when you said "derive PartialEq" did you mean *derive*
* nikomatsakis: I meant *derive* because `match` would follow the same semantics that derive would do (but without actually requiring a derive)
* joshtriplett: what is the property we want to keep? I guess that's the point, we could allow you to unsafe impl things, if you are saying that ...
* scottmcm: trait bounds is one reason, derive sets bounds that might not be the bounds you wanted
* scottmcm: this reminds me of deref patterns, too
* nikomatsakis: at the heart of are a few questions...
* what happens if you match on a constant? today, it has nothing to do with any trait impl, it "unfolds" the constant value into a pattern
* sometimes we can't do that, e.g. floats or raw pointers etc
* joshtriplett: or we might kind of rule out that you could ever do matching with user-specified behavior? could decide to keep it builtin?
* S-tracking-design-concerns seems right, we're not sure the correct design
* nikomatsakis: sure that what is implemented is NOT what we want, but not sure what we DO want
* joshtriplett: anybody up for writing up what we just discussed?
* nikomatsakis: I can write a quick note that we should do another design meeting (ACTION ITEM)

## Tracking issue for `?` operator and try blocks #31436

* simulacrum: labeled with design concerns, should we move on?
* joshtriplett: is that the current state? were those addressed by try trait v2?
* simulacrum: comment from Scott on Dec about a forthcoming RFC
* joshtriplett: sounds like that label was accurate

## Specialization tracking issue #31844

* nikomatsakis: outstanding design considerations
* joshtriplett: basically, is it sound, is it sufficiently safe to use?
* nikomatsakis: Aaron and I sketched an approach that we feel is clearly sound
* described in http://aturon.github.io/tech/2018/04/05/sound-specialization/
* and
* but it needs a proper write-up
* but also there were soundness issue around subtyping where it was being *used* unsoundly in libraries
* joshtriplett: wanted to make sure we have a clear picture
* simulacrum: some thought to be put into the syntax etc
* libstd demonstrates that it may not be the right design in terms of ergonomics
* nikomatsakis: really good point on a good source of data
* nikomatsakis: Jane's been talking to me about the error WG really wanting this
* joshtriplett: Jane, Mara, the8472 ...
* simulacrum: ...iterator shenanigans, right.

## tracking issue for naked functions #32408

* joshtriplett: Filed in 2016, but Nathaniel McCallum filed and then implemented *constrained naked functions* (i.e., you must stick an asm block in them and nothing else).
* Seems like they are on track to reasonably stabilize, has its own tracking issue
* joshtriplett: what is the nature that is more than the constrained variant and do we actually want it?
* nikomatsakis: I think we don't
* joshtriplett: maybe you're right but I'd like to confirm. It looks like naked functions allow you to write Rust code.
* nikomatsakis: I remember that even when they were proposed people were really unclear on what that was supposed to mean.
* joshtriplett: Don't know how to write a spec for a fn that has no stack frame.
* dbarksy: Can we unaccept an RFC or a tracking issue?
* joshtriplett: for unaccepting RFCs, what we've done is to close the issue, relabel the RFC, and add some text to the RFC itself.
* dbarsky: seems like this is a candidate for superceding?
* joshtriplett: agree, does anybody have an objection to rejecting non-constrained naked functions?
* nikomatsakis: sounds right, this feels like the right thing is to move to close, saying we think this is superceded by constrained naked functions, and giving folks a place to speak up
* joshtriplett: I'll do that (ACTION ITEM)

## pluggable panic implementations #32837

* nikomatsakis: predated panic=abort
* nikomatsakis: how much is this lang?
* joshtriplett: trying to see if anybody has asked for this
* simulacrum: only people I've seen who wanted this are people who want `-Cpanic=unwind` but want their own unwinder, and not whatever we ship for that target by default, but that's usually "I want LLVM unwind and not gcc libunwind" and hence more like...
* simulacrum: I think we should potentially close this in favor of a new RFC
* nikomatsakis: is this an impl detail of panic=abort? should we call it perma unstable?
* simulacrum: not sure how much this is featured gated vs things have to be named correctly
* joshtriplett: let's tag this perma-unstable to see if, now that we have panic=abort, anyone is specifically relying on it
* nikomatsakis: feels somewhat tied in with ffi-unwind
* joshtriplett: can you write a comment, simulacrum?
* simulacrum: yes (ACTION ITEM)
* joshtriplett: want to allow for possibility people want it, but see no evidence of that

## allocator traits and std heap #32838

* joshtriplett: tagged as "disposition-merge", tempted to tag this as "needs investigation" and move on
* simulacrum: we've definitely stabilized parts of this, I think we should just close it and open a new one
* nikomatsakis: suggest wg-allocators moves everything relevant into issues in the repo
* joshtriplett: I thought we had one for "needs investigation", but I don't know if that label still exists, maybe needs-summary is good enough?
* dbarsky: there was one, took me forever to find it, alex closed this on may 6 2019 but it got reopened since it's part of an unstable attribute. gankra repoened it.
* joshtriplett: currently this is the tracking issue pointed to by unstable features.
* joshtriplett: I'll just edit that comment further and say that the remainder of this post is no longer accurate.
* joshtriplett: what label? I wonder if this is at the point where that group ought to come talk to us (and maybe libs too) to figure out what is where.

## Tracking issue for #[cfg(target_has_atomic = ...)] #32976

* decided to stabilize in triage meeting yesterday, tagged as S-tracking-ready-to-stabilize

## `#[may_dangle]`, a refined dropck escape hatch (tracking issue for RFC 1327) #34761

* nikomatsakis: perma-unstable placeholder that was required to expose useful capabilities but not in a form we would expect to stabilize
* does the drop impl use `T` in any way but to drop it?
* what if T was `&'x u32`, does `'x` have to include the drop execution?
* if you mark it as "may dangle", it does not
* relevant because if you want to build an arena, it can't have cycles in it unless this is true

struct Foo<T: Debug> { t: T }

impl<T> Drop for Foo<T> {
    fn drop(&mut self) {
        println!("{:?}", self.t);
    }
}

* joshtriplett: sounds like perma unstable then
* nikomatsakis: this is basically a "special purpose" escape hatch from the general rule that all generic parameters have to be live over a function's execution. We probably want a general purpose escape hatch.
* joshtriplett: Might be worth doing a design meeting at some point
* nikomatsakis: Ralf sketched some interesting thoughts many years ago, I wouldn't call it high priority

## Tracking issue for global asm support #35119

* joshtriplett: I think this issue is probably not needed; it's either old asm (and superceded) or new asm (in which case it's tracked elsewhere).
* nikomatsakis: sounds like we should close it, or move to close it.
* joshtriplett: question is whether this is being used to track `global_asm!`
* nikomatsakis: ok, I don't really know
* joshtriplett: I'll write a quick comment cc'ing Amanieu

## Trackling issue for promoting `!` to a type

* joshtriplett: Mark?
* simulacrum: design concerns at this point
* simulacrum: there is room for discussion even if all the current concerns resolve themselves

## Exclusive range patterns #37854

* joshtriplett: anybody know the current state?
* nikomatsakis: they must work by now...right?
* joshtriplett: there were conflicts with slice pattern, I'll add needs-summary
* nikomatsakis: I think we stabilized something and there was some "rump" left over
* joshtriplett: right someone was poking at it
* nikomatsakis: I think bstrie was involved too?
* dbarsky: jubilee left a comment...?