I think these shortcuts could be really useful for array elements, but
for other variables I am really sceptical and I think they would do
more harm than good. Generally I do not really see any reason why a
variable should not be 'instanciated' before use.
So
+1 if this shortcut is implemented to only work for array elements.
-1 for any other variable type.
There are two issues here.
1. Suppression of notice. I agree, it is best done only for array
keys. It's not hard to initialise a variable with $var=null at the
beginning of a code block to avoid such a notice, and that is the
appropriate way to do it for variables.
2. Offering a shortcut for the common idiom isset($x) ? $x : $y in
line with the DRY design principle. A notice would never be emitted
here in any case. The problem is that this idiom is still in wide use
despite the shortcut ternary operator already provided, because an
isset() check is different to a boolean cast.
Some thoughts:
- Changing the existing behaviour of the ternary or shortcut ternary
operator is a bad idea. Good arguments have been offered against
it.
- The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
not about suppressing notices at all, but about offering a default
value, and the idiom quite probably only uses isset() because it
predated null in the language.
- If we view 2. in this way, the two problems are independent, and it
seems to me it would be best to solve them independently, rather
than with a single operator.
So, I suggest:
1. An array lookup mechanism that suppresses the notice for undefined
keys. It would work the same as regular array index lookups except
that the notice for undefined keys (and only for undefined keys)
would not be generated (it would not just be hidden, but would never
be even generated).
2. A shortcut for $x!==null ? $x : $y.
This allows people to opt out of either feature if they don't want it,
and doesn't encourage poor coding by suppressing warnings for undefined
variables.
Arguing about syntax is then a second step. However, my views on this
are:
1. Since we have @ meaning error-suppression already, why not reuse
that symbol, in a location that is unambiguous? $array@[$key] would
achieve this, right? It is localised to a single lookup, so can be as
precise as the coder wants. E.g. one could do
$array@["maybe-missing"]["expected"]@["maybe-missing"] and there's no
ambiguity about what is meant. Nesting is likewise unambiguous, so in
$array@[$lookups["key"]] if "key" does not exist, we still get a
notice.
2. We just need a single symbol, probably with multiple characters.
The key thing omitted by the shortcut is !==null so something that
evokes that would be a good choice. Two possibilities are using
something involving ? as in the ternary operator, or | as in the
logical short-circuiting or operator. E.g. we could have $x ??: $y or
$x ||| $y. However, both these somewhat imply either boolean tests or
boolean results, which would be best to avoid. This is not about
error suppression, so using @ would be unwise. Perhaps the best
character to use is $ because $ somewhat represents a variable. So
perhaps a good syntax would be $x $: $y. The $ somewhat evokes to me
'use the variable if you can (it is not null)' and the : somewhat
evokes 'otherwise', so I think it captures the meaning of the
operator.
In combination (which some people probably want), this looks like
$array@["key"] $: "default"
It's a bit different to what we're used to seeing, but the syntax is (1)
sensible and evocative of the right interpretation, and (2) not
misleading. I'd rather see something I'm unsure about and drives me back
to the docs than something that misleads me.
Ben.