T-lang meeting agenda

Meeting date: 2023-10-03

Attendance

Team members: nikomatsakis, tmandry, pnkfelix, scottmcm
Others: TC, eholk, fmease, waffle, CE

Meeting roles

Minutes, driver: TC

Scheduled meetings

2023-09-13: "RFC review Inherent Trait Impls – RFC#2375" #217
2023-09-20: "RFC review: Add f16 and f128 float types – RFC#3453" #218
2023-09-27: "RFC review: MaybeDangling – RFCS#3336" #219

Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.

Announcements or custom items

(Meeting attendees, feel free to add items here!)

Nominated RFCs, PRs, and issues

"Lifetime Capture Rules 2024" rfcs#3498

Link: https://github.com/rust-lang/rfcs/pull/3498

TC: In the design meeting on 2023-07-26, we discussed the new lifetime capture rules for Rust 2024, which were needed (for among other reasons) to unblock RPITIT, and we came to the following consensus:

Question: Are we ready to RFC this?

TC: If we were to propose an RFC with the text of this document, cleaned up lightly for the RFC format, and with the addition that Josh proposed (that if in the future we discover that too much code experiences overcapturing and needs to be desugared to TAIT, we should explore more ergonomic solutions), who here would check their box, by a show of hands?

joshtriplett: Hand.
tmandry: Hand.
nikomatsakis: Hand.
pnkfelix: Hand.

(scottmcm was not present in the meeting.)

TC: The proposed RFC has now been posted and the PR for it is up. Editorially, this document has certain improvements and clarifications from the one we discussed (prompted in part by that discussion), however it is exactly the same in all normative respects.

TC: We discussed this last week. I neglected to ask whether someone wanted to propose FCP merge so that people can start to check boxes. Does someone want to do that?

NM: The issue has been quiet. I'll propose FCP merge.

Consensus: We'll propose FCP merge.

"Stabilize `async fn` and return-position `impl Trait` in trait" rust#115822

Link: https://github.com/rust-lang/rust/pull/115822

TC: All of the open concerns have been resolved. This will move into FCP when @pnkfelix checks his box.

pnkfelix: I've been checking comments to make sure everything is covered. I think that everything is. It's not a reason to block it anyway. We should find a better way to make sure that everyone who has left a comment feels that their comment has been answered. I've checked my box. It's in FCP now.

NM: I'm thinking about the fact that publishing the answers to these questions in GH is about the least useful place for them. It'd be nice if we had a place in the docs or in the initiative repos for documenting the best usage patterns available.

CE: Regarding the issue specific issue raised, it's not possible to do this on stable. There is #116040.

CE: I want to lint against TAITs in trait signatures. There's also the point that people may want ATPIT instead of TAIT.

TC: Maybe we should discuss #116040 while we're here. It's labeled T-types not T-lang, but it may be worth discussion.

CE: There's probably no T-lang decision here as it's an impl of RFC 1214.

"const-eval: make misalignment a hard error" rust#115524

Link: https://github.com/rust-lang/rust/pull/115524

TC: In the 2023-09-19 meeting, we decided to propose FCP merge. Three boxes are unchecked (@joshtriplett, @pnkfelix, @scottmcm). Is there anything we could discuss to move this forward?

scottmcm: checked my box; should go FCP soon – oh, there it goes.

pnkfelix: I've checked my box also.

Consensus: It's going into FCP.

"const_eval: allow function pointer signatures containing &mut T in const contexts" rust#116015

Link: https://github.com/rust-lang/rust/pull/116015

TC: Oli nominated this for us:

Nominating for T-lang FCP as this enables more code to compile. Specifically this allows mutable references in const fn, as long as they are part of a function pointer signature. We already support function pointers on stable (but not calling them), and we forbid all mutable references. This check was overzealous and also forbade function pointers that had mutable references as arguments, even though there is no risk associated with that at all, as function pointers can't be used at compile-time anyway (except to pass them around).

tmandry: Can anyone summarize why we don't allow mutable references in const contexts?

CE: It commits us to a representation in CTFE that we may not want to commit to, is what I recall.

NM: I remember oli saying that there's not a good reason, but we're just being careful. We could ask.

CE: oli pointed out there is no risk here.

NM: I would like to see examples of places where muts would not be OK and why this one is different.

tmandry: …

scottmcm: It probably comes from a visitor that looks for &mut.

CE: Yes.

tmandry: I think we can FCP merge this. Is it T-types as well?

CE: I don't think it needs T-types.

NM: I think it's fine. I could be T-types.

tmandry: Okay, FCP merging.

pnkfelix: Where in the docs would the answer to tmandry's question appear?

NM: In my ideal world there would be a const generics repo. The rustc-dev-guide would be an option too.

tmandry: There should be a centralized place for all of these docs to live.

NM: Not sure I agree.

TC: I think what tmandry is saying is that these disparate repos are hard to find.

tmandry: +1.

tmandry: We're doing it this other way mostly just for access control.

CE: There is an issue:

https://github.com/rust-lang/rust/issues/57349

Consensus: We'll start an FCP merge.

"make matching on NaN a hard error" rust#116284

Link: https://github.com/rust-lang/rust/pull/116284

TC: RalfJ nominated this for us:

This is basically a trimmed-down version of #84045 that only makes matching specifically on NaNs a hard error. Those match arms are impossible to hit, so there's no way these arms are actually useful.

scottmcm: this means that changing a const from non-NAN to NAN would be a compilation-breaking change? I guess that's not really worse than other const changes that can also break stuff? But part of me says "deny-by-default lint" for this rather than hard error.

pnkfelix: Should we just add a pattern for is_nan?

CE: There's a difference between byte-wise equality and the other. Ralf wants to squash the issue completely.

scottmcm: I'm torn on this one. On the one hand, this is useless. But on the other, if we're going to allow matching on floats at all, it's strange for this to be a hard error.

waffle: If we end up allowing matching on floats that this should be a lint, that's what you're saying scottmcm?

nikomatsakis: This gives a warning that floats cannot be used in patterns…

fn main() {
    let x = 0.0;
    match x {
        0.0 ..= 1.0 => { }
        _ => { }
    }
}

NM: Either we disallow all floats or we make this a dead code warning.

scottmcm: Oh, interesting, this is a hard error: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=705ee0236c8794b67db134ad3dcc503f

error[E0030]: lower range bound must be less than or equal to upper
 --> src/lib.rs:3:9
  |
3 |         10..=2 => (),
  |         ^^ lower bound larger than upper bound

tmandry: If we remove NaN fro the table, then we can allow matching on ranges.

NM: Why disallow NaN?

tmandry: NaN isn't equal to itself. So why would we match on it?

NM: I'd like to get to a better understanding. Having an edge like this is much more like a lint. I can imagine code gen generating code that happens to result in a NaN for dead code. I'd like to understand the concern, if it's just "this is a unlikely to be what you wanted", that feels like a lint.

tmandry: I agree it should be a lint modulo const concerns.

tmandry: Not sure what to do about NaN in ranges.

scottmcm: Malformed ranges on patterns are a hard error already.

error[E0030]: lower range bound must be less than or equal to upper
 --> src/lib.rs:3:9
  |
3 |         10.0 ..= 2.0 => (),
  |         ^^^^ lower bound larger than upper bound

error[E0030]: lower range bound must be less than or equal to upper
 --> src/lib.rs:3:9
  |
3 |         10.0 ..= f32::NAN => (),
  |         ^^^^ lower bound larger than upper bound

error[E0030]: lower range bound must be less than or equal to upper
 --> src/lib.rs:3:9
  |
3 |         f32::NAN ..= f32::NAN => (),
  |         ^^^^^^^^ lower bound larger than upper bound

error[E0030]: lower range bound must be less than or equal to upper
 --> src/lib.rs:3:9
  |
3 |         f32::NAN ..= 15.15 => (),
  |         ^^^^^^^^ lower bound larger than upper bound

NM: You can match on NaN today and it has semantics. The question is, "are we open to changing it?"

tmandry: Two cases: malformed range that includes NaN. The other is matching on NaN directly. Do we want to handle these differently?

NM: Ralf has had different views over time. I want to know what he thinks we should do now. Are there concerns other than that people may be surprised? And what do we expect to do with floating point matching at this point?

waffle: There is one implementation concern. It's annoying to handle floats because they are not structural. Ralf is advocating against using the implementation concerns to skew the language design. I don't necessarily agree with that.

Consensus: We're going to wait to hear back from Ralf. Niko will post a comment about this discussion.

scottmcm: About SemVer. Changing a const is already a problem here. So one more isn't a big deal.

tmandry: The value of a const is already public.

scottmcm: Any change to a const is SemVer-scary.

"remove 'illegal_floating_point_literal_pattern' future-compat lint" rust#116098

Link: https://github.com/rust-lang/rust/pull/116098

TC: RalfJ nominated this for us. This is related to the nomination above. RalfJ:

@rust-lang/lang in #84045 you decided to not turn "match on float" into a hard error. However, we kept emitting a lint which said that we would eventually make this a hard error. Clearly that's not consistent, so this PR proposes to remove the lint.

However, there's not a ton of rationale discussed in that thread. We have people saying they are matching on floats and see no reason why that would be rejected; we have the point that == works on floats and has all the same issues so why would we complain only about match-based comparison.

OTOH, RFC 1445 is fairly clear about rejecting floats in patterns due to them being "not structural" (e.g., 0.0 and -0.0 compare equal but can make a difference when used with copysign).

So would be good to see if you are still feeling the same way about making this a hard error or not, and why. I don't personally have a preference either way, I just don't want to have a lint that says "will be made a hard error" when at the same time a PR that makes it a hard error gets rejected saying "actually we don't want to make this a hard error". :)

scottmcm: I don't know how to reconcile this one with the previous one.

tmandry: For ranges I could see it.

scottmcm: Ranges involving NaN are already hard errors (as part of the general rule that ranges in patterns require a <= b, which always fails with NAN)

waffle: For context, this PR was submitted before the one we discussed above.

tmandry: There's a lot of discussion on this issue.

waffle: There is even more discussion in Zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/matching.20and.20.60Eq.60/near/391366382

scottmcm: This feels like we need a design meeting. We can't decide what the semantics of const are in a triage meeting. I want it settled absolutely.

tmandry: Does someone want to open an issue in the lang-team repo?

TC: Who has the context for this?

NM: Ralf and Oli. Maybe Boxy.

scottmcm: I'll open the issue.

Consensus: This needs a design meeting. We'll open an issue.

Meeting issue: https://github.com/rust-lang/lang-team/issues/222

"Prepare removal of `auto trait` syntax in favor of new attribute `#[rustc_auto_trait]`" rust#116126

Link: https://github.com/rust-lang/rust/pull/116126

TC: This has been discussed in a Zulip thread.

TC: fmease has nominated this and has written up an explanation of the change.

fmease: As I understand, we'll never make the ability to define new auto traits for users on stable.

fmease: I propose we remove the syntax for this to discourage use of this. As it turns out, there are backward compatibility concerns as certain big projects do use the syntax on stable.

fmease: PyO3 uses this for example.

NM: Do we have a summary of what they're using this for?

waffle: PyO3 are bindings for Python. Python has a GIL. If your structure uses things related to GIL… it's like thread safety but specific to Python. There's an interesting summary here:

https://github.com/rust-lang/rust/issues/13231#issuecomment-1737586128

It gives an example of how auto traits can be used outside of the standard library in a coherent way.

I'm proposing that we not remove auto traits and do eventually stabilize them.

fmease: The question needs to first be answered of whether we want to mark auto traits internal.

tmandry: Did we ever make a T-lang decision on this?

scottmcm: There is a backlog bonanza tag saying it wasn't on stabilization track right now.

NM: There wasn't an official decision per-se. But we recognized the additional SemVer risk is pretty steep. But the use-cases here are pretty compelling. For many sound safety-related APIs it's useful to be able to search for all of the things.

scottmcm: I'd love to push on marker traits a bit more.

TC: Yosh may have thoughts here about how effects may relate to this.

NM: I'm comfortable with marking them as internal for the time being, but I'm reluctant to break existing projects.

tmandry: +1.

CE: Do we already lint against other accidentally-stabilized syntaxes in the parser?

fmease: There is an open issue on that.

fmease: My PR should only break nightly users not stable users.

scottmcm: Agreed with NM. Maybe we should leave the syntax for now. There is churn in removing it.

tmandry: The churn is not necessary. There are seemingly use-cases.

fmease: It may be contradictory to mark it as internal but allow PyO3 and others to start using it.

scottmcm: Could we start linting against it?

waffle: But there are coherent usages. Why would we want to discourage experimentation with those? The concern with auto traits was "that we need to know to opt-out of auto traits created by various crates". But it doesn't seem to be a real concern because traits defined by crates need to be coherent. So you don't need to opt-out randomly if you don't interact with that system.

scottmcm: What I object to there is the compositionality of it. E.g. if I were using a different python wrapper.

fmease: That is interesting.

NM: Why would your type opt-out?

scottmcm: If I need to opt out of a different Python library's auto trait but I didn't know to opt out of PyO3's.

NM: That's a good question. But I would expect that PyO3 would say that if you get to raw pointers etc. that you're not GIL-safe. I.e. you don't need to think about it outside of the crate. It should only ever be that I opt back in.

scottmcm: We do have negative impls for auto traits.

NM: The intent is that by and large you don't need to use them. There's a flawed premise that you can make a soundness guarantee.

waffle: If we're unsure whether we want to go forward on auto traits, we shouldn't make them internal.

scottmcm: I agree about the syntax change. What is the intent of the internal features lint?

waffle: It's basically that you should never use it unless you're reimplementing the standard library. Maybe there should be a new lint.

TC: unmaintained

NM: +1.

CE: I'll open a PR to gate the syntax. There's a compiler bug here. It'll be a warning.

Consensus: There's no consensus to remove the syntax. CE will open a PR about the more general issue of nightly syntax leaking to stable. There's no consensus yet to mark this as internal. We may want to discuss a new unmaintained lint.

(The meeting ended here.)

"`.await` does not perform autoref or autoderef" rust#111546

Link: https://github.com/rust-lang/rust/issues/111546

TC: This was nominated for T-lang (and for T-types) by WG-async. @tmandry said:

We discussed this in a recent wg-async meeting (notes). The consensus was that we thought the change was well-motivated. At the same time, we want to be cautious about introducing problems (namely backwards compatibility).

There should probably be a crater run of this change, and we should also work through any problematic interactions that could be caused by this change. (@rust-lang/types should probably weigh in.)

The main motivation for the change is the analogy to .method(), as well as to wanting async and sync to feel similarly convenient in most cases.

Note that there is another analogy that works against this, the analogy to IntoIterator, where the lang-effect form (for _ in foo {}) does not do autoref/autoderef. However, given that this looks very different from foo.await, and taking a reference with that form is significantly more convenient (for x in &foo or for x in foo.iter() vs (&foo).await), it seemed the analogy was stretched pretty thin. So we elected to put more weight on the above two considerations.

That being said, this change would need lang team signoff. You can consider this comment wg-async's official recommendation to the lang team.

"MaybeDangling" rfcs#3336

Link: https://github.com/rust-lang/rfcs/pull/3336

TC: We discussed this in an RFC read on 2023-09-27. @scottmcm said that he would propose FCP merge.

"Tracking Issue for the Rust specification" rust#113527

Link: https://github.com/rust-lang/rust/issues/113527

TC: We've created a new Zulip stream for this work.

TC: A job description for the editor has been discussed. There seems to be consensus to move forward on the hiring process.

TC: There is outstanding discussion on the appropriate name of this document.

TC: There is an outstanding discussion ongoing about the goals of the specification.

TC: Niko has proposed to create the team, with pnkfelix and Mara as the leads, and for that team to work to draft a new set of requirements.

"Disallow references to `static mut` [Edition Idea]" rust#114447

Link: https://github.com/rust-lang/rust/issues/114447

TC: We discussed on 2023-09-05 and the consensus was in favor of going in this direction. We left a comment with the path forward and labeled it E-help-wanted.

TC: Are there any particular people we might want to ping who we know might have an interest in this?

"Non-temporal stores (and _mm_stream operations in stdarch) break our memory model" rust#114582

Link: https://github.com/rust-lang/rust/issues/114582

TC: We discussed this on 2023-08-15.

@RalfJ points out that certain compiler intrinsics don't fit within the memory model of the Rust Abstract Machine. For this one in particular, in the time between doing a non-temporal store and before doing a store fence, things are a bit nuts. But this has a performance benefit as it bypasses the cache, so "fixing" it by eliminating the performance benefit isn't a good option. The meeting consensus was to table this while looking for ways to raise awareness. As @scottmcm said, "it wouldn't be the first thing you could do in unsafe that turns out to be sketchy."

TC: Some discussion followed about this issue after the meeting.

"dyn Trait comparison should not include the vtable pointer" rust#106447

Link: https://github.com/rust-lang/rust/issues/106447

TC: The FCP to close this issue has been completed. However, @Amanieu is still looking for a way forward. There's been some discussion on Zulip about this.

TC: We discussed this in the 2023-09-26 triage meeting without a full resolution, but decided that adding ptr::addr_eq may be one small step forward. @pnkfelix proposed this in the ticket and then to T-libs-api. @dtolnay seconded the request and asked for a PR.

"RFC: Implementable trait aliases" rfcs#3437

Link: https://github.com/rust-lang/rfcs/pull/3437

TC: This RFC has also been proposed for a design meeting as an RFC read, but it has not yet been scheduled for one.

TC: We discussed this in the 2023-09-26 triage meeting. We decided that this needed more discussion and that we'd leave a comment about what was discussed in the issue. Niko has posted that comment.

"Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418

Link: https://github.com/rust-lang/rust/pull/106418

TC: We discussed in the 2023-09-26 meeting. We decided to simply let T-libs-api know about what we had discussed. Niko left a comment to the effect that "right now we seem to have no good options."

TC: This is now I-libs-api-nominated.

"Support overriding `warnings` level for a specific lint via command line" rust#113307

Link: https://github.com/rust-lang/rust/pull/113307

TC: We discussed in the 2023-09-26 meeting, but were unsure of the question we were being asked. We've reiterated on the issue a request for clarification.

"Report monomorphization time errors in dead code, too" rust#112879

Link: https://github.com/rust-lang/rust/pull/112879

TC: We're waiting on @oli to investigate an unexpected incremental build-time regression. I made sure that @oli knows that, and knows that we resolved the fundamental question that was blocking this earlier in RFC 3477.