Decide whether to separate cfg(version("..")) and cfg_has_version

[traviscross]

In this stabilization,

• Stabilize #[cfg(version(...))] #141137

it was observed that stabilizing cfg(version("..")) doesn't help people immediately, because they have to wait for their MSRV to exceed the first version in which cfg(version("..")) is supported. To mitigate this, a new mechanism, cfg(has_cfg_version) was proposed.

Since then, @joshtriplett has raised good points about how this mechanism would be difficult to use. See this comment:

• Stabilize #[cfg(version(...))] #141137 (comment)

We need to decide whether we want to consider these questions together, or whether we'd accept a stabilization of cfg(version("..")) that sets this question aside.

cc @rust-lang/lang @est31 @jieyouxu @ehuss

Tracking:

• Tracking issue for RFC 2523, #[cfg(version(..))] #64796
• Tracking Issue for cfg_version cargo#15531

[traviscross]

Proposal: For the reasons outlined by @joshtriplett, I propose that we separate these questions and reopen the stabilization PR for cfg(version("..")) in its original form. We can separately and later consider the question of cfg(has_cfg_version).

@rfcbot poll

[rfcbot]

Team member @traviscross has asked teams: T-lang, for consensus on:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

[traviscross]

I'm going to check @scottmcm's box, since he signaled unambiguously in the meeting support for stabilizing cfg(version("..")) alone, and @joshtriplett's given his statements in the PR, but feel free to adjust of course.

[joshtriplett]

FWIW, I do think there's potential value in making it easier to adopt cfg(version(...)) more quickly. I don't believe has_cfg_version as proposed solves that, due to the issues I wrote about, and I think it'll make cfg(version(...)) harder and/or more confusing to adopt (given that there will be a simple path that ignores old MSRV and a complicated path that doesn't).

In other words: please take my comments as concerns with the concrete proposal that was made, rather than any objection to the underlying value of wishing to better support the transition for people whose MSRVs are older than cfg(version(...)) support.

[tmandry]

We discussed this in the lang call today. I was hoping that cfg_has_version would be a simple and uncontroversial addition. It turned out to be simple to implement, but not entirely uncontroversial. I'm therefore willing to check my box and not block cfg(version("..")) as promised.

In tandem with the stabilization of cfg(version("..")), I plan to write up a simple RFC for cfg_has_version. My hope is to get them in as close together as possible to simplify the user story.

@rfcbot reviewed

[traviscross]

@est31: That's your cue. Once you're ready, we'd welcome a new v2 stabilization PR for cfg(version("..")) with a report that discusses the considerations related to cfg_has_version and notes that is being handled separately.

[est31]

Thanks. I will file a stabilization PR in the coming days.