If that is the case, then how can bareword filehandles be removed? Or are bareword filehandles supported in Perl7 but omitted from "Standard Perl" and our fellow monk WaywardCode was confused?

I believe the situation itself is confusing, and I apologize if I have made it more so by assuming everyone had watched the conference talks already in my first post. Here is what I know:

EDIT: The outline below assumes the worst outcome sometimes, and even I expect events to veer towards sanity as events unfold. Also, I'm not at all against perl changing, but I don't find the particulars given in these announcements very inspiring.

• Sawyer claimed the default settings (when you run perl with no switches or pragmas) in version 7 will change.
  • Obviously this will break old scripts unless they are fixed up or they add compatibility pragmas.
  • In the talk he says (paraphrasing) if you have bad code that doesn't run against the new defaults and you don't want to change it, you are going to be unhappy, and that's ok.
• He committed to turning on strict and warnings on video, and alluded to several more he'd like to add, such as signatures
• Meanwhile, brian d foy issues an announcement post claiming the likely removals are:
  • indirect object notation
  • bareword filehandles (except maybe the standard filehandles)
  • "fake" multidimensional arrays+hashes
  • change the prototype syntax to the new :prototype syntax
• People on p5p are trying to figure out how to make code with prototypes work across the versions. Maybe they will succeed, but the answer isn't obvious.
• Some on p5p are calling for use v7 to enable the features, rather than changing all the defaults, but so far Sawyer says that won't accomplish his goals. If you read also in this mail you can see that at least some on p5p were blindsided by this announcement (or possibly are feigning it, depending on which side of the argument you believe).
• In foy's post, he says "your code should work if it's not a mess." Again, what's with the condescending talk about old code in these announcements. I mean, seriously, what gives!
• Now, v7 is just v5.32 with some settings changed, and you can change them back by adding pragmas. But, the key thing to notice is that they explicitly offer that kind of compatibility for one major version. It's spelled out in the article, and mentioned in the video.
• You might say "well I'll be dead by version 8" but:
  • Perl versions before 5 came at a rapid clip
  • Sawyer said he was really looking forward to v8, and not in the sense of "my grandkids will love it"
• So in a couple years when they move to v8, until there's clarification, I have to assume we could lose our ability to get back to something resembling perl5 defaults altogether. In the video, Sawyer's example is that in v8 they would completely remove indirect object calls, but nothing was called out as perma-safe.
• Some poor soul left a question on p5p about whether strict would really apply to v7 one-liners, and got no reply since Jun 26.
• Meanwhile, at the same conference where we just heard Sawyer talking about how he is excited to be able to remove things from the language, we get a talk where he unveils a BNF-restricted "Standard Perl" which omits all kinds of additional perl-isms. He says it enforces code that he likes to write, and how he would like to teach the language to new people. Somehow, he did not predict that this would worry people like me. Whether it worries you is up to you.

This sounds to me like Sawyer's goals are to cause yet another fork or to push people to Raku by blowing up Perl. Removing indirect object notation will break every module on CPAN that does I/O and does not use IO::Handle syntax, not to mention the IO syntax provides C++-like new THING (@args) constructors for programmers that want them. TIMTOWTDI.

He says it enforces code that he likes to write, and how he would like to teach the language to new people.

This is particularly incendiary. Whatever happened to TIMTOWTDI? I thought that was a core value of Perl...

I believe 100% he thinks this is best for Perl, and has the best of intentions. The goal of catering to hypothetical new Perl users by aggressively updating defaults or working on a restricted subset that’s easier to teach doesn’t agree with me personally but I’m just a nobody enthusiast shaking my head. They are trying to do good here.

I brought up this topic in the context of Larry’s “postmodern” talk because back then, he was talking about what made Perl different as a strength, and these recent talks seem so focused on *not* defying a new user’s expectations. I don’t read bad intentions into that, but it was very noticeable.

what about declared subroutines?

Without brackets they become barewords.

I find the whole, 4ish "how do I pass bareword FH to subroutines?" by "referencing of a glob" syntax like \*DATA extremely confusing.

I won't miss them.

I only wished I wouldn't find so many perldocs and modules on CPAN still advertising them in their POD.

And if you still insist on bareword FHs, you can still let a sub return them.

sub FH {
   return $fh;
}
[download]

I believe that sub would need to be:

sub FH { our $FH; return $FH }
[download]

So does this lead to a use filehandles pragma that will (mostly) work for declaring filehandles by establishing the proper subs?

This

 sub FH :lvalue  { my $fh }

should do.

But I don't have the time to test it in all edge cases.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}