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
