Jochen,
> On 14 Aug 2018, at 6:25 PM, Jochen Theodorou <blackd...@gmx.org> wrote:
> Am 14.08.2018 um 15:23 schrieb ocs@ocs:
>> H2,
>>> However, “a+b” should work as one would expect
>> Absolutely. Me, I very definitely expect that if a happens to be null, the
>> result is null too. (With b null it depends on the details of a.plus
>> implementation.)
>
> the counter example is null plus String though
Not for me. In my world, if I am adding a string to a non-existent object, I
very much do expect the result is still a non-existent object. Precisely the
same as if I has been trying to turn it to lowercase or to count its character
or anything.
Whilst I definitely do not suggest forcing this POV to others, to me, it seems
perfectly reasonable and 100 per cent intuitive.
Besides, it actually (and expectably) does work so, if I use the method-syntax
to be able to use safe navigation:
===
254 /tmp> <q.groovy
String s=null
println "Should be null: ${s?.plus('foo')}"
255 /tmp> /usr/local/groovy-2.4.15/bin/groovy q
WARNING: An illegal reflective access operation has occurred
... ...
Should be null: null
256 /tmp>
===
which is perfectly right. Similarly, a hypothetical “null?+'foo'” or
“@ImplicitSafeNavigation ... null+foo” should return null as well, to keep
consistent.
(Incidentally, do you — or anyone else — happen to know how to get rid of those
pesky warnings?)
Thanks and all the best,
OC
