I do. To my mind, undef is not a value, it is the absence of a value. eq tests whether two values are equal, so applying it to the absence of a value (undef) seems rather odd.

Or, to look at it another way, what you're really trying to do is to determine whether $var is defined or not, so defined $var seems like the obvious way of doing so. $var eq undef looks to me like you're checking to see whether $var has a certain value rather than checking to see if it's defined.

Well, it really depends on what you think "eq" should do, and how it should work. There are benefits to both approaches, I think.

If you think "eq" should compare two strings, then comparing one string against something that is specifically a special value that is *NOT* a string should flag a warning. (Let's assume warnings are always turned on for the purposes of this discussion.)

If you think that "eq" should tell you whether two things are "set the same", then "eq" should "compare silently" to undef(); that is, the comparison should not generate a warning a string is compared to undef. This has the advantage of convenience and simplicity, but it also has a few drawbacks.

In this alternative definition of "eq", to be consistant, you probably want every undefined expression to compare silently equal to every other undefined expression. If you do that, however, you might not catch all the kinds of errors that you may want to catch. For example, the following code will flag a warning under the current meaning of "eq", but wouldn't for the alternative meaning.

$x = input_line(); # input_line returns undef on failure
$y = input_line(); 
if ( $x eq $y ) {
    # checks to see if both lines are equal  
}
[download]

Of course, you could always make "eq" have a third, more complicated definition: (a) when two strings are compared, "eq" generates warnings if one string is undefined, BUT (b) when one string and the constant "undef" are compared, "eq" will not generate any warnings.

This third definition would probably work, but I'm not convinced it's any simpler than the existing system. Right now, all you have to decide is whether the comparison involves undef, or if it doesn't. The third definition requires that you distinguish between two subtly different "undefined values": the undefined value that comes from an expression vs. the undefined value that comes from a special constant. That sounds like too much work to me!

The current definition of "eq" (and other comparison operators) seems like the simplest tradeoff between convenience, and power that I can think of, so that's why I favour it, despite the initial awkwardness of getting used to using defined() all the time.