On Mon, Jun 29, 2026 at 5:34 PM Nika Krasnova <[email protected]> wrote: > > - 1.94.1: core::cfg_select present behind #![feature(cfg_select)], with > the final builtin behavior (single-brace expression position works).
The tracking issue says the latest change was in Rust 1.91.0. Did it not work there? Were there changes after that? > Does that work for you, or would you rather take the gate and drop > expression-operand support? Hmm... The end goal would to use `core::cfg_select`, so in general it is a good idea to use the "real one" as soon as possible. In addition, we can always wait for any case that doesn't work in the fallback (as long as the behavior is the same for the cases that do work). Therefore, we could limit ourselves to what would work today with the fallback. If I understand you correctly, you are saying that even with the conversion here, we wouldn't even need the expression case, no? What is annoying about that is that there is definitely a risk of someone using one of the cases that don't work on the fallback but never actually testing on the minimum version -- even if we don't have those today, someone may add it. And while it is "just" a compile error that we would likely catch early in linux-next (like similar things we need to handle), it is still painful. So, yeah, I appreciate the advantage of having just a single compile path, and if we can make it so that people cannot fall into cases that would require extra cleanups/migration later on when we move to `core`'s (even if `core` supports those), then that should be good, i.e. if we want to go with this one in all versions, then we should make sure we only allow that subset that cleanly maps to the future. Now, to be honest, the easiest is to just wait a year and then start using `core`'s directly... i.e. it is not like we are in a rush to start using it anyway... Cheers, Miguel
