(Meeting attendees, feel free to add items here!)
Link: https://github.com/rust-lang/lang-team/issues/102
Link: https://github.com/rust-lang/lang-team/issues/125
Link: https://github.com/rust-lang/lang-team/issues/126
Link: https://github.com/rust-lang/lang-team/issues/135
Link: https://github.com/rust-lang/lang-team/issues/139
Josh: Are you still excited by this, Felix?
Felix: hesitantly Yes?
Josh: Are you enthusiastic enough to get buy-in and a plan?
Felix: I dunno? I've said what I have to say.
Josh: We have a process for seconding, but not for "hmm, it hasn't gotten a second". What does deciding "I guess not" look like?
Mark: Didn't we have something for this?
Josh: We discussed time-based?
Mark: Didn't Niko post a PR to the lang-team repo adding a process?
Scott: How should we weigh the "that sounds cool vs I'm scared about the implication"
Josh: If this is about an experiment, then the second might be appropriate? If someone feels like they're not sure but an experiment might convince them, it might be appropriate to second. Also, thanks Mark for linking the process doc.
Felix: The only updates I might want are to split out the proc macro case. That would still help the non_exhaustive cases, for example.
Josh: That might make me more interested in doing it.
Scott: Though I don't know how essential the "nice for examples" use is.
Link: https://github.com/rust-lang/lang-team/issues/143
#[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147Link: https://github.com/rust-lang/lang-team/issues/147
Link: https://github.com/rust-lang/lang-team/issues/150
Link: https://github.com/rust-lang/lang-team/issues/151
(moved to FCP close 14 days ago, can we close?)
Josh: New comment with a similar request, but the macro solution should still work here.
Josh: Could someone verify, and then summarize and close? With a playground demonstrating a macro.
Felix & Scott: I don't want to make that playground.
Scott: bravely volunteers to summarize
None.
Link: https://github.com/rust-lang/rfcs/pull/3191
Josh: This is ready to merge, anyone interested?
Felix: I can merge this.
David: What about the approach of having MIRI evaluate a Debug or similar? Is that just too far off?
Josh: That'd be a large non-Rust project; it's an interesting idea but not a short-term solution. In the mean time we need something that works with what debuggers actually do, but that would definitely be a nice project – albeit perhaps a non-Rust project. Generally we have to balance making rust work with other things vs other things working with rust, and this is a good example of that.
David: I might know some lldb resources who could be interested.
Check your boxes!
target configuration " rfcs#3239Link: https://github.com/rust-lang/rfcs/pull/3239
Josh: This is a updated version of a previous one we talked about, resolving previous issues. Please take a look and see whether you have any new concern.
Felix: is it an and/or?
Josh: It should be an all, but if the RFC doesn't seem clear in that regard, please make a concern or a GitHub suggestion.
David: Does this have any interaction with the link attribute?
Josh: oh, since it has some built-in cfg?
David: Windows-sys does some odd things that this might help with
Josh: Check how it interacts, and make a suggestion.
David: will take a look today or tomorrow
Link: https://github.com/rust-lang/rust/issues/92980
Link: https://github.com/rust-lang/rust/pull/93313
let else" rust#93628Link: https://github.com/rust-lang/rust/pull/93628
Felix: This is still blocked on temporary lifetimes.
let_chains in Rust 1.62.0" rust#94927Link: https://github.com/rust-lang/rust/pull/94927
Scott: What about the interaction with let else for this
Josh: Definitely not a let-else inside a chain. The other way around is a more reasonable question, but we can consider at a later time. But if there's a 1-way door we're missing, raise it.
Scott: Ok, that resolves my
Felix: What about this PR? https://github.com/rust-lang/rust/pull/94974
Josh: It's testing both.
Felix: What's something that could be reasonable?
Scott: I think this one coulse potentially be reasonable
let Some(b) = a && let Some(c) = b else {
return;
};
Josh: An else makes it infallible, which makes having it in a condition make not sense any more.
Felix: I'm convinced we're not going through any 1-way doors here.
for<'a> syntax when declaring closures" rfcs#3216Link: https://github.com/rust-lang/rfcs/pull/3216
let_chains] Forbid let inside parentheses" rust#95008Link: https://github.com/rust-lang/rust/pull/95008
Link: https://github.com/rust-lang/lang-team/issues/102
Link: https://github.com/rust-lang/lang-team/issues/126
Link: https://github.com/rust-lang/lang-team/issues/135
Link: https://github.com/rust-lang/lang-team/issues/147
Link: https://github.com/rust-lang/lang-team/issues/150
Link: https://github.com/rust-lang/lang-team/issues/151
None.
Link: https://github.com/rust-lang/rfcs/pull/3240
Josh: I think this is ready for consideration.
Josh: Was tempted to rfcbot merge it, but wanted some informal double-check here first.
yaahc: Its either ready or very close. Some questions, like how colud this be extended to nonstd. Parallel proposal that hasn't materialized from Mara with ideas about filtering visibility of items based on rust-version field. Can express "only support rust 1.45" and you wouldn't even see the item on later versions. But if that were the only solution, then bumping Rust version is still a potentially breaking change. So the idea proposed in RFC PR 3240 is still worth considering.
Josh: Can see the benefits of that, but concerned about the implication of breakage in bumping Rust versions.
yaahc: Also an autoref behavior question, very much open question. How does this disambiguation interact with autoref, and how that can be used to replace how array IntoIter is handled in an ad-hoc manner today.
yaahc: Its not just array IntoIter, there are other similar cases that could likewise benefit. But we still need to figure out whether that works.
Josh: Is that a blocker for the RFC design?
yaahc: Not sure. May have to try it to see.
Josh: Might be worth updating RFC with those two additions, and comment in zulip with suggestion on how to move forward to resolve the autoref question (i.e. should that be resolved prior to experimentation, or if it could be resolved via experimentation.)
Josh: I want to reduce team scope to just T-lang, not T-compiler and T-libs
yaahc: I wanted T-compiler to be aware of it and provide feedback on the approach
pnkfelix: I think the answer there is to post a T-compiler MCP after T-lang has signed off on RFC itself.
Link: https://github.com/rust-lang/rfcs/pull/2442
Josh: This has been updated to incoporate all feedback, especially with autoref mechanism to allow calls on all kinds of chains.
enhanced_binary_op feature" rust#93049Link: https://github.com/rust-lang/rust/pull/93049
Josh: Could we get more clarity on the ask here?
Some lack of clarity on what the change was related to ||; the original ask was just related to handling of &&.
for<'a> syntax when declaring closures" rfcs#3216Link: https://github.com/rust-lang/rfcs/pull/3216
Link: https://github.com/rust-lang/rfcs/pull/3245
Link: https://github.com/rust-lang/rust/pull/93313
impl Fn() -> impl Trait in return position" rust#93582Link: https://github.com/rust-lang/rust/pull/93582
let_chains in Rust 1.62.0" rust#94927Link: https://github.com/rust-lang/rust/pull/94927
Link: https://github.com/rust-lang/rust/pull/95295
Link: https://github.com/rust-lang/rust/pull/95372
Link: https://github.com/rust-lang/reference/pull/1152
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe