enable select preview flags after a certain version

[timotheecour]

refs discussion in #18711 (comment), see all the arguments presented in that thread.

I'd prefer when (NimMajor, NimMinor) > (1,4) and (NimMajor, NimMinor) != (1,6) but using 1.7 as done here is a compromise in the meantime which at least ensures that 1.7 will have those flags enabled.

As discussed in that thread, there's no automatic feature activation going on; these are hand-selected preview flags, each of which can be debated as comment to this PR.

Note that there's no gain in delaying switching on preview flags past next release, all it'd achieve is causing extra work for client code to benefit from what's going to be the default.

links

see also https://github.com/nim-lang/Nim/wiki/Creating-a-release

[juancarlospaco]

This is nice, I think Nim should work to reduce the amount of experimental flags for stable releases.

[Araq]

As discussed in that thread, there's no automatic feature activation going on; these are hand-selected preview flags, each of which can be debated as comment to this PR.

I don't understand. We release 1.8 and the feature will be active, how is that not automatic? Preview features are for people to try, provide feedback and only if no severe problems have been reported for some time they become non-preview features, this should be the case for 1.8 for these particular features, but maybe we have to delay it until 1.10. Either way, this is "automatic" and sets a weird precedent -- "don't make me think about which features to include in a release when I have to do a release".

[timotheecour]

One major point of on-by-default in devel is to increase its exposure to people tracking devel so you can actually gather feedback on the feature and identify issues earlier rather than later; off-by-default means little exposure/use/feedback if there are any bugs with the design they may go undetected;

with what you're suggesting, you'd turn on the feature right before some release (whether 1.8 or later), ie it would have little exposure.

with what I'm suggesting, it'd have a long exposure time in devel before the release is due; 1.6 would still be released with default-off, but exposure would accrue in devel.

If by the time 1.8 is due, the feature is deemed safe, 1.8 would have it on, as planned; else, at any point in time before 1.8 we can decide that 1.8 should still have it off, regardless of whether devel should keep it on or off for further ironing out.

It's a sane design, which ensures we provide features with good exposure in stable releases while providing exposure to select experimental features in devel, for as long as needed in the devel branch; ie, a feature can be turned on immediately in devel, even if the feature won't turn on-by-default in stable until a later TBD release (eg delayed until 1.10); in this PR i took a more conservative stance of 1.7 but immediately would've worked too with this logic.

[ringabout]

How about isOdd(NimMinor) and NimMinor >= 7? So it is always enabled on devel and disabled on release? then make a note on https://github.com/nim-lang/Nim/wiki/Creating-a-release to decide whether to enable it on release. And we need to explicitly note it on docs to tell uses how nimPreviewX works.

[arnetheduck]

as mentioned in the other comment, devel should reflect the next release so that library developers and the community have time to prepare their code for that release, as it will be released - a general -d:nimPreviewFeatures would be a low-effort way that people can enable in their CI if they also want to test what experimental and unverified features might land in the future, should they prove themselves to actually be useful.

[timotheecour]

How about isOdd(NimMinor) and NimMinor >= 7

ok, i've pushed a commit which now uses: when (NimMajor, NimMinor) >= (1, 5) and (NimMinor mod 2) == 1: ; it addresses the contention point of pre-specifying a stable release where these become default; I can follow up with a note in https://github.com/nim-lang/Nim/wiki/Creating-a-release if/when this PR is accepted.

as mentioned in the other comment, devel should reflect the next release

no, you use version branches for that, as is common in many other projects; it works not just for upcoming 1.6 but also as preview for other point releases in 1.4 (eg for upcoming 1.4.10):

to preview 1.2.14, you track version-1-2
to preview 1.4.10, you track version-1-4
to preview 1.6.0, you track version-1-6

note that version-1-6 isn't yet created, but should; it can be kept syncrhonized with devel by rebasing it regularly.

[arnetheduck]

If there is demand for a feature, people will want to turn it on and test it - if there's not, it's worth considering why, and address those points - there's nothing like a useless feature that nobody except its author uses once to make their PR - it's a useful smell test with regards to adoption that interest is kept up with skin in the game, beyond a "like" on an RFC, before asking the community to shoulder the burden of maintaining it and adapting their code for it.

[konsumlamm]

If there is demand for a feature, people will want to turn it on and test it - if there's not, it's worth considering why, and address those points - there's nothing like a useless feature that nobody except its author uses once to make their PR - it's a useful smell test with regards to adoption that interest is kept up with skin in the game, beyond a "like" on an RFC, before asking the community to shoulder the burden of maintaining it and adapting their code for it.

I wouldn't be surprised if there'd be no demand, simply because noone knows about the feature in the first place.

[arnetheduck]

I wouldn't be surprised if there'd be no demand, simply because noone knows about the feature in the first place.

so .. you're saying the features are being added/developed without any demand / use case for them? I mean, if nobody knows about them due to the default value of a flag, something is already wrong - it's not the flag itself that is the problem.

[konsumlamm]

I wouldn't be surprised if there'd be no demand, simply because noone knows about the feature in the first place.

so .. you're saying the features are being added/developed without any demand / use case for them? I mean, if nobody knows about them due to the default value of a flag, something is already wrong - it's not the flag itself that is the problem.

No, I mean that only few people look at the RFCs and that the new experimental features are barely documented, so anyone who doesn't look at the RFCs/PRs will have a hard time finding them.

[arnetheduck]

No, I mean that only few people look at the RFCs and that the new experimental features are barely documented, so anyone who doesn't look at the RFCs/PRs will have a hard time finding them.

Does the default value of a flag address the lack of documentation, lackluster response during RFC phase and disinterest in the PR flow?

[konsumlamm]

Does the default value of a flag address the lack of documentation, lackluster response during RFC phase and disinterest in the PR flow?

No, it was never my intention to imply that. I just wanted to point out that "people don't use this experimental feature" doesn't necessarily mean that it's useless, it might as well mean that most people just don't know it exists.

[timotheecour]

[..] features are being added/developed without any demand / use case for them?
[..] there's nothing like a useless feature that nobody except its author uses once to make their PR
[..] every flag someone with an itch to scratch manages to throw into stdlib
[+ many similar comments of yours]

yes, clearly, things like roundtrip floats and 10-70x performance improvement for $float is a niche feature no-one cares or asked about.

see #18008

• closes stdlib needs ryu for compact and performant float to string #13365
• closes Fast and accurate float to string conversion (ryu) needed-libraries#104
• fixes Lossy json serialization/deserialization round-trip for floats #13196
• fixes json: insufficient precision for float64 serialization #15397
• fixes https://forum.nim-lang.org/t/5983
• fixes https://forum.nim-lang.org/t/7850

You keep making generic claims without ever looking into the specifics.

[Araq]

While I can see the merits of your idea, I think it's too risky. "Half automated feature opt-ins for Nim devel, still automatically disabled in the upcoming release" seems the worst kind of automation. Instead please remind us to enable the code after 1.6 is out.