I ++ your version because I prefer it to mine. But...

It is not at all comparable to testing $. in that sense.

Of course it is.

The result of the expression, $. == 0, is a flag who's only purpose is to detect the end-of-file condition. This is the express and only purpose of eof.

The difference is that eof can operate on a named filehandle whereas, $. is global and can be reset by a read operation on any filehandle. Call a function from within the loop that accesses a totally different filehandle and you completely screw the loop. This is not true for eof.

There’s someone more prominent than me who said that function is almost always a bad choice.

If you read the context of the link you gave, you'll see that it's author is saying that it is unnecessary to explicitly test eof in order to terminate a read loop, because

Perl returns an unambiguous end-of-file condition by yielding an undefined value. ... The while(<FH>) construction even does so automatically.

Which is an entirely different context to the one under discussion.

The result of the expression, $. == 0, is a flag who's only purpose is to detect the end-of-file condition. This is the express and only purpose of eof.

$. == 0 tests whether I’m looking at the first line, which, in my reality, is not exactly the same as testing for end-of-file…

Update: err, almost. In my reality, $. == 0 is a bug and nothing but a bug. It was supposed to be $. == 1 of course. Quite how I missed that even though I actually tested the code, I don’t know.

it's author is saying that it is unnecessary to explicitly test eof in order to terminate a read loop, [… w]hich is an entirely different context to the one under discussion.

So the last if eof(DATA); line in your code is not a test to prematurely terminate the loop?

Are we discussing some alternate universe? :-)

Makeshifts last the longest.