a typo ... will produce a warning

I know, since I'm the one who corrected you about this. And since lexicals cause compile-time errors, this is an argument for lexicals instead of bareword filehandles.

"being careful" ... conventions ... in good practice

These three are the same thing, and we've been over this too.

Bareword filehandles do not clash with sub names at all

You're mistaken, see the references I gave.

That was not specific to filehandles ... These scopes have the same extent.

Once again you're just explaining something to me that I already know, while missing the point I was making: you said lexicals have an additional risk, which I agreed with, while pointing out that the scope of the potential issue is both easily remedied and the issue arguably smaller than all the issues that bareword filehandles have.

A lexical declared at file-scope is indistinguishable from a global variable in good practice.

There's that insistence again. And just in case your point happens to be that code using bareword filehandles, when correctly written, runs just like code using lexicals, then while true, I think this fails to recognize the action-at-a-distance issue I named. While the cost of this may not be immediately apparent and you may not have personally run into this so you may not know this feeling, ask anyone who's had to maintain code that uses globals how brittle that feels, or especially anyone who's had to debug an action-at-a-distance bug what that's like and what the cost was.

I find similar insistences that a lexical declared at file-scope is somehow not effectively a global variable merely because it is not in the symbol table similarly misleading.

Who's insisting this?? Not me...

Lexical variables declared at file scope have the same risks as global variables (use strict / use vars) and need to be recognized as such.

Once again I fail to see how this has anything to do with an argument for using bareword filehandles instead of lexicals.

At file-scope, lexicals have the same problem.

That lexicals and barewords share an issue or two may be true, but neither is this a counterargument to anything I said, nor is this what you said that I was responding to. Saying barewords have "exactly the same effect" while not acknowledging that barewords have more problems than lexicals is misleading and potentially dangerous to people who aren't aware of the issues. Imagine someone writing a short, single-package daemon:

print STATUSMAIL "Error report:\n";
print STAIUSMAIL "IMPORTANT ERROR\n" if some_rare_error_condition();
[download]

Lexicals would have obviously prevented this. And yes, I'm aware of "but conventions" and "but warnings" and "but testing" - I find the analogy in the anonymous post fitting: my car may or may not have a crumplench zone, airbags, and autopilot, and yes, seatbelts may not be a silver bullet, can be used wrong, and can cause bruises, but guess what, I'm still going to argue that the habit of always putting on a seatbelt is a Good Thing for many good reasons (while educating people on how to do it right when necessary), and one major reason is that there are other people on the road too. And I'm still going to take issue with people who say otherwise, and to me, "I strongly favor the use of bareword filehandles at top-level in preference to declaring lexicals at file-scope and thinking that you are safe" reads as "I strongly favor not wearing a seatbelt in specific circumstances in preference to wearing a seatbelt and thinking that driving is perfectly safe." In response to my arguments, you just seem to keep repeating various permutations of "seatbelts and driving overall aren't perfectly safe", which may be true, but is not an argument against seatbelts. And just to be clear, yes I'm equating lexicals to seatbelts because they protect against all of the issues of bareword filehandles, and I have yet to hear arguments against this.

Taking a step back, at this point I'm just seeing a lot of nitpicking, explaining things I know, and repetitions of things we've been over, and continuing the "discussion" in this manner is not helpful. So far, I've carefully read all of your posts in hopes that I'd find an actual, concrete argument for bareword filehandles (as I asked), and also arguments against the various issues that I named (that isn't nitpicking), because I was honestly curious if either exist. But at this point I'm more worried that I've insulted your personal coding style, which I said isn't why I'm arguing this, so I'm sorry if that's the case.

What I'm arguing for is what to recommend to others, in particular (but not limited to) newcomers - in that respect, my viewpoint remains unchanged from what I said: I don't really see what arguments for bareword filehandles are left, other than making newcomers to the language aware of the fact that they exist but are not a best practice.

Edit: Clarified second paragraph.

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}