T-lang meeting agenda
Attendance
- Team members: nikomatsakis, joshtriplett, cramertj, scottmcm, pnkfelix
- Others: simulacrum, m-ou-se
Meeting roles
- Action item scribe: simulacrum
- Note-taker: nikomatsakis
Scheduled meetings
Upcoming
From planning meeting notes:
- June 16 – Structural equality <– Niko had no time for this, deschedule
- June 23 – Possible: Atomic follow-up <– Felix?
- June 30 – Lang team process proposal <– nikomatsakis still plans to prep
Plan:
- Cancel June 16
- Evaluate June 23 meeting next week based on progress (can swap topics)
Already had these meetings
Need to close the issues, we should push minutes and notes.
Action item review
Pending lang team project proposals
"MCP: Allowing the compiler to eagerly drop values" lang-team#86
Link: https://github.com/rust-lang/lang-team/issues/86
- Status: Niko started write-up, no progress since then.
"negative impls integrated into coherence" lang-team#96
Link: https://github.com/rust-lang/lang-team/issues/96
- Status: Seconded.
- There is some interaction with specialization:
- The example here is not a specialization (
&str: !Error) but it would be kind of nice if this "just worked".
- One could make the case that a "rounded" version of specialization might accept this case.
impl From<&str> for Box<dyn Error>> { }
impl<E> From<E> for Box<dyn Error>>
where
E: Error, { }
- This case is expressing something different from specialization.
- But often the times that cramertj wants specialization isn't strictly "making a more specialized version", but rather some way to deal with overlaps that are either theoretically possible or just uninteresting.
- Josh has run into this case as well, where the compiler doesn't understand that there's no actual overlap. Josh would prefer to use negative impls to tell the compiler there's no overlap, rather than using specialization to say the "overlap" is OK.
- Mara: The negative impl allows you to augment the upstream crate by promising not to have overlap, whereas specialization lets the user deal with overlap if it occurs.
- Josh: Might you sometimes use negative impl in downstream crate?
- cramertj: Why not have str implement Error?
- Niko: seems like a good thing to to the project group, but I think it has to do.
- Niko: there are times you don't want to use specialization, because you don't want
default on your items, e.g. for associated types.
- scottmcm: it's worth nothing that we could use this to replace some fundamentals, e.g. by making
str not a function, so that we can make the closure traits not fundamental.
- Niko: right, it was done so that you can make arguments either a closure or a value
- Josh: Have we looked into what it means to fully generalize fundamental types?
- Josh: Is there still motivation for this if we merge core/alloc/std?
- Niko: Have been interested for some time, for things like "all Copy types, and Vec"
- Answer: yes, but less. Also it seems like that merge would take longer to make a reality than negative impls.
- ed.: same is true for specialization
- scottmcm: We could consider allowing negative bounds not by the absence of a positive impl, but by the presence of an explicit negative impl.
- This might enable some specialiation use cases as well.
PRs on the lang-team repo
"Initial draft of copy ergonomics design note" lang-team#62
Link: https://github.com/rust-lang/lang-team/pull/62
Assigned to: pnkfelix
"Autoref/autoderef for operators" lang-team#63
Link: https://github.com/rust-lang/lang-team/pull/63
Assigned to: scottmcm
"Auto trait design note" lang-team#69
Link: https://github.com/rust-lang/lang-team/pull/69
Assigned to: nikomatsakis
"Add design notes for function-type Default implementation discussion" lang-team#71
Link: https://github.com/rust-lang/lang-team/pull/71
Assigned to: nikomatsakis
"Add draft of variadic notes" lang-team#76
Link: https://github.com/rust-lang/lang-team/pull/76
Assigned to: cramertj
Proposed FCPs
Check your boxes!
"Calling methods on generic parameters of const fns" rfcs#2632
Link: https://github.com/rust-lang/rfcs/pull/2632
- Pending action item for nikomatsakis to talk to const generics group.
- Has been over a year since we last checked boxes.
"RFC: Add target configuration" rfcs#2991
Link: https://github.com/rust-lang/rfcs/pull/2991
- Josh wanted shorthand syntax for matching specific components of the triple, rather than the full target triple.
- Mara: "For most cross-platform libaries in the ecosystem it's probably an antipattern to match on a specific target triple. But for other software it's quite common that it's built for two or three specific targets (e.g. a company making software for specific hardware). In those cases, it would be a lot more readable to match exactly on the few target triples that are supported, rather than having to translate those into separate components."
- Concern:
- people could over-specialize
- a lot of the interest was specific to wasm32-unknown-unknown
- Mara: it could happen that people are overly general by matching against more targets than they meant to, as well, right?
- I couldn't convince myself that matching all the parts might not accidentally match more than I meant.
- ,Niko: Why not support both?
- Josh: people might misuse the wrong thing
- Josh: I don't think this is likely to be a problem where you 2 of the 3 components. But there are platforms like arc, risc-v, etc where many details are wedged into those target strings (e.g., the ABI). We have logic to handle that in our parsed out version. Exposing the full target string then exposes all the squirelly little flags.
- Mara: But if that's specifically what I wanted?
- Niko: So why NOT do both?
- Mara: bikeshed to figure out the right split outs.
- Josh: What we have now is a split-out version but we don't have a shorthand to make it easier. People might match the target just for the brevity.
- Right now you would do
#[cfg(all(target_os=..., target_family=...))]
- Niko: so we're just exposing those with a distinct syntax, right? So you can write
target(os=..., ...), so the bikeshedding has basically been done, right?
- Josh: Agreed. I'd be happy with "let's allow both and request the RFC specify the shorthand version".
- Mara: So you don't want to extend the set of things we parse?
- Niko: agreed, just make it more convenient to access, extending is a distinct RFC.
- Note: target_abi is https://github.com/rust-lang/rfcs/pull/2992
- Consensus:
- Allow matching exact target triple
- Introduce a shorthand syntax to access existing
target_xxx variables, but not introduce any new such variables
- Action item: Josh to summarize consensus
"Tracking issue for RFC 2523, #[cfg(version(..))]" rust#64796
Link: https://github.com/rust-lang/rust/issues/64796
- Continued progress towards implementing subset of accessible.
- Josh: not sure how much implementation energy there is at the moment, though.
- Niko: sounds like we need to write mentoring instructions
- Action item: nikomatsakis to add to the project board.
"Support forwarding caller location through trait object method call" rust#81360
Link: https://github.com/rust-lang/rust/pull/81360
- Niko proposed FCP
- If you have it on the trait, is it required on the impl?
- Answer: no, can't make it a hard error, backwards compatibility.
- We could potentially warn on this.
- pnkfelix: I'm trying to understand the logic. In principle you could have some impls that don't use
#[track_caller] because they don't need it and (with static dispatch, at least) don't want the extra parameter.
- Niko: perf hit seems theoretical.
- Josh: We've had PRs to add
#[track_caller] to more methods, and for especially hot methods in the stdlib the perf test suite does see a difference.
- Felix: Not necessarily runtime cost, could be the compiler getting slower because it has more work to do.
"Stabilize RFC 2345: Allow panicking in constants" rust#85194
Link: https://github.com/rust-lang/rust/issues/85194
- Blocked on edition interactions, afaik
- Should we close and encourage someone to come with a write-up?
- Josh: why is this a blocker?
- Niko: I don't like things working on rust 2018 that don't work in rust 2021
- Mara: We don't have a way to migrate
- Josh: what about panic with a string and no format arguments, can that work?
- Mara: that's exactly what we undid in Rust 2021 because it accepted too many things
- Josh: what about a function that only takes strings?
- Mara: that exists,
panic_str, but it doesn't access any arguments like {}.
- Mara: we could expose this function, but I'd rather not
- Mara:
panic_any only exists in std and not in core
- and we don't want to make const panic incompatible with with no-std
- Josh: do we have to CLOSE this, or can we just leave it as blocked on this concern?
- Niko: I'd rather just record that we are in support and close the issue. Just a procedural note, but I think the purpose of this issue was to decide whether to stabilize NOW (not at arbitrary points in the future).
- Josh: Support recording consensus and then closing, to make the path clear for the future point where we have a way to do a const panic without the format machinery (or when the format machinery works in const).
Active FCPs
"Ignore derived Clone and Debug implementations during dead code analysis" rust#85200
Link: https://github.com/rust-lang/rust/pull/85200
"negative impls integrated into coherence" lang-team#96
Link: https://github.com/rust-lang/lang-team/issues/96
P-critical issues
"iter::Fuse is unsound with how specialization currently behaves around HRTB fn pointers" rust#85863
Link: https://github.com/rust-lang/rust/issues/85863
- Recent compiler team meetings proposed to back out some but not all specializations.
- Actual problems seem fairly unlikely but this is clearly a blocker to resolve or consider for stabilization specialization.
- Proposal: No further action needed at this time, we should do an overall assessment of unsoundness at some point in future and triage appropriately.
Nominated RFCs, PRs and issues
"add back support for inner attributes on non-block expressions?" rust#84879
Link: https://github.com/rust-lang/rust/issues/84879
- pnkfelix opened a PR here for match, right?
- PR #85193: "Re-add support for parsing (and pretty-printing) inner-attributes in match body"
- If so, can we close
"RFC: let-else statements" rfcs#3137
Link: https://github.com/rust-lang/rfcs/pull/3137
- Active discussion, Josh seems to be pushing
- Niko: Added to project board.
"Tracking issue for RFC 2523, #[cfg(version(..))]" rust#64796
Link: https://github.com/rust-lang/rust/issues/64796
"Allow deriving Into and TryFrom for primitive enums" rust#81642
Link: https://github.com/rust-lang/rust/pull/81642
- Is this a lang concern?
- scottmcm: I don't think so, except in that it might impact our feelings on things like
as.
"Stabilize "RangeFrom" patterns in 1.54" rust#83918
Link: https://github.com/rust-lang/rust/pull/83918
- Question is whether to permit
.. at the top-level of a slice pattern
- Do we want
[..3], for example?
let [octobyte 0..8, rest @ ..] = byteslice;
- Current status: PR leaves that corner case as unstable.
"Deny float matches" rust#84045
Link: https://github.com/rust-lang/rust/pull/84045
- Blocked on structural equality meeting.
"Add expr202x macro pattern" rust#84364
Link: https://github.com/rust-lang/rust/pull/84364
- Waiting for pnkfelix to request specific grammar change or something like that?
"Allow struct and enum to contain inner attrs" rust#84414
Link: https://github.com/rust-lang/rust/pull/84414
- Pending for some time with no feedback
- We do now support
match { #![foo] ... }
- Thoughts?
"implement Default for all arrays" rust#84838
Link: https://github.com/rust-lang/rust/pull/84838
- Latest status unchanged
- What do we need to do to move this forward?
- Given the uncertainty around specialization, Niko is feeling a mite nervous.
- However: even in the absence of specialization, is this worth a "special case" to support? Arguably yes.
"Fix how allow/warn/deny/forbid warnings is handled" rust#85298
Link: https://github.com/rust-lang/rust/pull/85298
"Stabilize bindings_after_at" rust#85305
Link: https://github.com/rust-lang/rust/pull/85305
"Stabilize const_fn_transmute, const_fn_union" rust#85769
Link: https://github.com/rust-lang/rust/pull/85769
(Deprioritized or blocked issues from the list above)
"Stabilize RFC 2345: Allow panicking in constants" rust#85194
Link: https://github.com/rust-lang/rust/issues/85194
"Check for union field accesses in THIR unsafeck" rust#85263
Link: https://github.com/rust-lang/rust/pull/85263
- requires detailed review, skip
"Support forwarding caller location through trait object method call" rust#81360
Link: https://github.com/rust-lang/rust/pull/81360
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe