On Fri, 18 Nov 2016, Sven Schreiber wrote:
Hi,
I stumbled again over the issue that a "null" default for list types as a
function argument requires different checks than "null" defaults for a
string, for example.
(For lists, only nelem(listinput)==0 will really work, whereas for string and
other types one has to use !exists(stringinput).)
This has been discussed before on the mailing list(s). However, if I look up
the function reference for exists() or nelem() or isnull(), this doesn't seem
to be mentioned, but it would be useful.
I'm not sure what's the best thing to do about this. I believe the
original thought about lists was that if you say
list L = null
you get a valid list object with no members. So, by extension, if a
list parameter to a function is marked as having a default of "null",
this suggests that in the absence of an argument the parameter slot
should be automatically filled with a list with no members -- and
that's what happens at present.
However, there's an inconsistency with strings, as you say.
Unfortunately (as it now seems to me), you can say
string s = null
and get an empty string. So one could argue that for consistency with
lists we should automatically supply a zero-length string when a
string parameter is marked with a "null" default and no argument is
given. I say "unfortunately" because there's a perfectly good and
unambiguous way to get an empty string, namely
string s = ""
and allowing "string s = null" seems not quite right.
Anyway... we could regularize this by dropping the current practice of
manufacturing an empty list corresponding to no-argument, although
this would mean that "null" has a somewhat different meaning on the
right-hand side of an assignment (empty object) and as the default for
a function argument (non-existent). Urgh. It's hard to see a way out
of this that's not rather nastily backward-incompatible.
Allin