@tonycoz can you force re-push your branch so we can test travis?

Oops, think I broke it

I too was thinking about quite a few "no"-style pragmata to add:

no indirect;
no parser::prototypes;  # bans first { ... } @items, requires  first(sub { ... }, @items)
no constsub::invocants  # bans PF_UNIX->foo; requires  PF_UNIX()->foo

It starts to suggest a general idea that actually we want an antifeature to mirror `feature:

no antifeature qw( direct parser_protos constsub_invocants ... );

This is mostly a PoC, the intent of putting it in feature is so it's trivially addable to a feature bundle, so it could be enabled with use 5.xx (though we seem to be out of bits for that, which is an issue for more than this.)

This heavily penalizes sub calls for everyone not opting in and using 'my $obj = new Foo' form, which is half CPAN (grep.cpan.me shows 1 to 25 of more than 1000 distributions). Should we have a more efficient way for feature detection, instead of memcpy + a hash lookup?

I am very surprised as well. I had a priori imagined that feature flags were a bitmask of similar style to the warnings and hints bits, such that a runtime check is just bitwise & test. Knowing they are this expensive suddenly makes me more hesitant to add others. :/

Is it something we could look at?

I'll take a look once I get back and recover from the flights.

Does this affect fake indirect syntax like print and exec?

Does this affect fake indirect syntax like print and exec?

Not for print at least, the test code (briefly) checks that it still works. I'll add a check for exec (it doesn't need to run, just compile) once I get back to this after re-working feature checks.

may want to add those checks for say and system too then - not sure how many more examples there are

The main hold on this form me right now is discussion on where we're going and how we're getting there (similarly for #17212), I think this is part of where we're going, but (reasonably) the p5h discussions were pretty high level.

Is the current negative here acceptable? Ideas for alternatives?

There was a thumbs down for the antifeature idea without discussion.

Whether this is managed in perl code using feature.pm or not, I do believe it should still use the feature mechanism (which is now much faster.)

I think it makes more sense to have it as an indirect feature that's enabled by default, and can be turned off by no feature 'indirect'; and possibly removed from a future version bundle, like we did with array_base.

I've pushed this to the branch ilmari/feature-indirect (1be847c).

I more like 'use feature "noindirect"' for consistency (it should be, at least somewhere).

Consistency with what? We have no other features with "no" in the name (e.g. we didn't have no_array_base when we removed support for setting $[). The CPAN pragma this is modelled on is no indirect, not use noindirect.

One question is whether we should leave it like it is currently, with intuit_method just returning false for indirect method calls, which leads to unintuitive errors like

Bareword found where operator expected at - line 19, near "new Foo"
       (Do you need to predeclare new?)
syntax error at - line 19, near "new Foo"

or if it would be better to give an error explicitly saying that the indirect method calls are disabled.

This is superseded by #17477, closing.