Considering all the feedback and discussion I've seen so far, I hereby retract my earlier proposals in the 'handling undef better' messages and offer new ones instead, which hopefully address the issues you collectively have raised.

At the root of the issues I see here is that the meaning of 'undef' is overloaded, and perhaps should be split into multiple concepts that are addressed with different keywords or class names.

Here are some concepts that undef either has been in practice or was previously proposed to be used for:

1. The state that a new container has after it has been declared (or allocated) but before any value has been assigned to it, such as with "my $x;".

That concept is probably the most befitting of terminology like 'undef', as those words sound like verbs which say what was not *done* with a container. Aliases for the same concept would be 'unset' or 'unassigned'.

2. A flag that says "we know that some value is supposed to go here, but we don't know what that value is yet, and we're holding a place for it". This flag would normally be used in the place of an actual value in a value expression.

That concept is potentially in line with what SQL's NULL means.

3. A flag that says we know that some operation failed, such as would be exploited in the "<failing-expr> err <deal-with-it-or-die>" situations.

This concept is like an exception which isn't thrown but returned.

4. A flag that says "we will become the context-derived 'none' value as needed, since we weren't yet told to be something else".

This concept is like what programmers expect when they simply use "empty" variables in expressions and expect them to DWIM, like become 0 or '' or false.

So, in an effort to have different meanings look different, I put forward these suggestions:

1. I accept the proposal that we just make another class that implements the SQL concept of a null value, perhaps named Null or SQL::Null, rather than having this behaviour in the core language, so that should simplify the rest of the discussion. If someone wants undefs to propagate through expressions like SQL's NULLs do, rather than failing or defaulting, then this can be done with the new class. A Null object would be defined but false. It would overload standard operators so that most expressions involving it would propagate a Null object, or compare unequally as desired. Therefore, this sort of behaviour will be isolated and standard data types won't behave this way by default.

2. Modify the 'Exceptions' section of S04 so that built-in functions return a 'error' or 'failure' or 'exception' if they fail, instead of an "interesting value of undef". The behaviour and handling of or response to these is essentially unchanged, but the value is called something more distinctive and it is not called 'undef'. Instead of testing for .defined(), invoke a different method like .failed() or .error() instead; invoking .defined() on an error should perhaps return true instead of false. Perhaps update err() to activate on the error rather than or in addition to undef.

3. Have the functionality of 'use fatal' turned on by default in large programs, though not one-liners, and it can be turned off otherwise. It is safer to have them brought to your attention where you make a conscious effort to respond to or dismiss them.

4. An expression or statement having an 'err' would impose a try-block around the expression it is attached to, so the right thing still happens when errors are thrown by default. And 'err' is a conscious effort to deal.

5. Autovivification in larger programs should not happen by default, unless you have something like 'use autovivify;'. But with one-liners it would work by default.

6. Attempts to use undef where a defined value is expected, such as wherever they currently generate warnings, should be upgraded to a stricture and fail by default in larger programs. But like with other strictures, this would be turned off by default in one-liners. If the DWIM behaviour is wanted in larger programs, one can say 'no strict undefs;' or such.

There may be remaining holes in my suggestions, but hopefully I dealt with the worst ones from the preceeding first draft.

-- Darren Duncan

Reply via email to