Feature guard the removal of apostrophe as a package separator

[book]

0c81a5c9ca0287c0ee954a71b1bffdeb2cb3e9c8 merged the removal of ' as a package separator.

After more discussion, the PSC believes it would be better to make the removal guarded by a feature. (Similar to what was done with the indirect, multidimensional and bareword_filehandles features.)

That feature would be included in the :default feature bundle and all bundles up to :5.40. It wouldn't be included in :5.42. The main benefit would be that none of the unmaintained modules on CPAN and elsewhere would break, while newer code would not be able to the apostrophe any more.

It has been suggested that the only really surprising/problematic aspect of ' as a package separator is in string interpolation (e.g. "This is $owner's house" would reference the package variable $owner::s). We think that if the feature is disabled, it might has well be disabled entirely, including for subroutines (e.g. isn't as provided by Test::More —Note: this specific subroutine has been deprecated in recent versions of Test::More).

The proposed name for the feature (which is unlikely to ever be enabled manually, so there's no need to consider ease of typing): apostrophe_as_package_separator.

See also: Putting apostrophe as a package separator behind a feature.

[leonerd]

That feature would be included in the :5.42 feature bundle.

Did you mean to say it wouldn't be included in the :5.42 bundle, just the default; much like indirect etc..?

[book]

That feature would be included in the :5.42 feature bundle.

Did you mean to say it wouldn't be included in the :5.42 bundle, just the default; much like indirect etc..?

Indeed. I meant included as in no feature 'apostrophe_as_package_separator'.

Fixed the original message to clarify.

[tonycoz]

apostrophe as package separate isn't just a source thing - it was also done internally in many places, typically converting apostrophe separated names into :: separated names before further processing.

If this is made conditional on the feature I could see it causing problems when passing symbol names between code with the feature (' in names enabled as by default) and code without the feature.

So I'd be inclined to just make the ' in symbols be featured guarded only in source and the API functions that deal with symbol names would always handle ' in names.

Arguments for/against welcome.

[book]

So I'd be inclined to just make the ' in symbols be featured guarded only in source and the API functions that deal with symbol names would always handle ' in names.

Is there a chance that this would leak and produce unexpected results?

In my understanding, this is just syntax. With the feature enabled, it's possible to use ' instead of :: in package names, and it's not when the feature is disabled. Whatever exists in the packages themselves is not affected, just the way it's reached or referenced.

So it seems to me (a core neophyte), that being guarded in source is sufficient.

[book]

This will affect #22517 and #22511.

[tonycoz]

So I'd be inclined to just make the ' in symbols be featured guarded only in source and the API functions that deal with symbol names would always handle ' in names.

Is there a chance that this would leak and produce unexpected results?

It seems unlikely, especially since these APIs have done this for most of perl5.

Note that with the current state (apostrophe in names removed) APIs still accept apostrophes, just as they accept most symbols, but they aren't translated to ::.

In my understanding, this is just syntax. With the feature enabled, it's possible to use ' instead of :: in package names, and it's not when the feature is disabled. Whatever exists in the packages themselves is not affected, just the way it's reached or referenced.

Right.

So it seems to me (a core neophyte), that being guarded in source is sufficient.

Ok.