There's no need for a new feature name - given/when/smartmatch was always historically guarded by the "switch" feature, changing this would break code that specifically enables (or disables, which I've done) the switch feature.

You're also suggesting adding this feature to the default bundle, even though it wasn't included in the default bundle previously. It was included in all other bundles (5.10 onwards).

So as far as I can see what needs to be done is:

• revert the removal (reinstates "switch" to feature)
• remove the feature from the 5.42 bundle
• remove any deprecating messages/documentation

Actually, switch was removed from versioned bundles starting from v5.35, so it doesn't need to be removed from later bundles.

Unfortunately, the 'switch' feature only dictates the availability of the given/when keywords, not the smartmatch operator. So in my opinion, it's appropriate to add a corrolary 'smartmatch' feature and remove it from the bundle in the same way; and the 'switch' feature should require the 'smartmatch' feature as necessary for its implementation, and conversely disabling 'smartmatch' must disable 'switch'.

Yes, the point of no feature 'smartmatch' would be to disable ~~.

I think the two features are actually orthogonal: it's possible to use given/when without ~~, and it's also possible to use ~~ without given/when.

$ perl -E 'say $^V; say "a" ~~ qr/a/'
Smartmatch is deprecated at -e line 1.
v5.38.2
1

Thanks, I never used smartmatch beyond test code /me removes boot from mouth.

I'll add the smartmatch feature as mentioned.

The feature dependency is something new and I'm not sure how it should behave:

• no feature "smartmatch"; - also disables the switch feature (as visible via the feature api):

use v5.10; # switch and smartmatch enabled
no feature "smartmatch"; # also force disables switch
use feature "smartmatch"; # but this doesn't enable switch
BEGIN { print feature::feature_enabled("switch"); } # false

• no feature "smartmatch"; - prevents the switch keywords being recognized even if the "switch" feature is enabled (simplest to implement, I think)

use v5.10;
no feature "smartmatch"; 
BEGIN { print feature::feature_enabled("switch"); } # true
given ($x) { # syntax error
}

• use feature "switch"; no feature "smartmatch"; - throws an error?

something else?

Yes, the point of no feature 'smartmatch' would be to disable ~~.

I think the two features are actually orthogonal: it's possible to use given/when without ~~, and it's also possible to use ~~ without given/when.

It is possible to use given/when without ~~, but it is implicitly used depending on the expression being matched, so I'm not sure what should happen if 'switch' is enabled but 'smartmatch' is not in those cases. I suggest doing whatever is simplest since both of these features will be deprecated/not available in modern code.

I think it's best to keep them independent.

If one does use feature 'switch'; and the implicit smartmatch, it should probably work. However, using an explicit ~~ without the smartmatch feature should fail (i.e. the feature enables the actual parsing of the operator).

I think it's best to keep them independent.

Concur.

If one does use feature 'switch'; and the implicit smartmatch, it should probably work. However, using an explicit ~~ without the smartmatch feature should fail (i.e. the feature enables the actual parsing of the operator).

That would complicate things, because when really does a ~~ op under the hood in such cases.

If it does a smartmatch under the hood, that's fine. The feature should only control the ~~ syntax, not the underlying op.

See PR #22766