You may make your recommendations, and I will make my recommendations. What I strongly oppose is removing features from the language that touts TIMTOWTDI without very, very, very good reasons, and the arguments against bareword filehandles do not meet that bar in my view.

I have a significant background in C, where all variables must be declared and the compiler will always catch typos (unless the typo refers to another declared variable with a compatible type) but issues of scope are similar, although the available scopes and extents are different from those in Perl. I see Perl file-scope lexicals as equivalent to static variables declared at file scope in C. They can be a useful tool, and certainly are preferable in most cases to ordinary globals, which appear in a common namespace across all modules in a C program, but are still best avoided unless you really do need that variable to be in the static data segment — nearly all actual data should be dynamically allocated on the heap and pointers held in local variables or itself held in local variables. But Perl does not put all globals in a common namespace: Perl has packages, which C lacks. Perl "globals" are actually stored in those packages, and standard practice in Perl 5 is to limit the reach of a package to a single source file. Therefore, "globals" and file-scope lexicals actually have the same scope and the same risks.

I reject the seatbelt analogy for this reason. (And I personally always wear my seatbelt when driving.) From my view, this is more like an "Emperor's New Clothes" situation where people are wearing sashes (that look like seatbelts) and acting as if they are wearing seatbelts and getting upset when it is pointed out that the sashes do not actually anchor to the car. File-scope lexicals look like lexicals, but have effectively the same scope as globals. In terms of surprise action-at-a-distance, they carry the same risks.

This is not to say that lexical filehandles are completely useless at top-level, as you have mentioned before, code is often lifted out of a sub for presentation in a SSCCE, and lexical filehandles are (with rare exceptions) the only proper option in a sub, but file-scope lexicals walk like globals and quack like globals. They are not, therefore, chickens.

removing features from the language

You're mistaken. Temporarily retracted while the discussion about Perl 8+ is ongoing; Perl 7 will however not remove them.

Therefore, "globals" and file-scope lexicals actually have the same scope ...

That's another whole paragraph explaining things that I know (I too have a background in C and plenty more) to support a point nobody is disputing.

... and the same risks.

No, this does not follow from the explanation you gave, since among other things, it ignores that bareword filehandles are not protected against typos like lexicals are.

File-scope lexicals look like lexicals, but have effectively the same scope as globals.

More repetition of already discussed and undisputed points.

In terms of surprise action-at-a-distance, they carry the same risks.

No, because this ignores the issues of bareword filehandles clashing with package and sub names, among others.

You continuing to "stick your head in the sand" and ignore the disadvantages of bareword filehandles and advantages of lexical filehandles will not make them go away. This is not the basis for a rational discussion, so I'm out.

> File-scope lexicals look like lexicals, but have effectively the same scope as globals. In terms of surprise action-at-a-distance, they carry the same risks.

Nope, again, there are plenty of ways to avoid a lexical to be closed over, like writing the main code after the subs are declared or putting a block around it.

And people who ignore lexical filehandles, don't know about packages either.

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

«...writing the main code after the subs are declared or putting a block around it.»

You mean something like this I guess:

#!/usr/bin/env perl

use strict;
use warnings;

KARL: {
    nose();
}

sub nose {...;}

__END__
[download]

I wrote my code many years like this and I can’t tell how often I’ve been blamed for it.

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

If you put a block around a file-scope lexical, it is not a file-scope lexical anymore. Writing the main code after subs are defined is another "just be careful" convention — it works (until the convention is broken), but if you do not accept conventions as legitimate solutions to problems with bareword filehandles, then why do you accept conventions as solutions to problems with lexicals?

The last issue of programmer ignorance is not a problem that can be solved by changing the language, only by educating the programmers about the language in which they write.