Proposal: Elvis and Other Null-Safe Operators
markmahieu at googlemail.com
Sun Apr 5 04:40:55 PDT 2009
Revisiting an email from a couple of weeks ago...
On 19 Mar 2009, at 17:18, Stephen Colebourne wrote:
> Neal Gafter wrote:
>> On Thu, Mar 19, 2009 at 1:26 AM, Jacek Kolodziejczyk
>> <jacek.p.kolodziejczyk at gmail.com> wrote:
>>> In my opinion the most obtrusive part in the current state of
>>> is assumption that the invocation on null object should always
>>> return null.
>>> If I understand it correctly the following would break at runtime,
>>> because null cannot be assigned to boolean:
>>> List list = null;
>>> boolean b = list?.isEmpty();
>> That would be a compile-time error because of the incompatibility
>> between null and boolean.
> The intention is that you can write a combination to handle this with
> the submitted Coin proposal:
> List list = null;
> boolean b = list?.isEmpty() ?: true;
I don't understand how that combination is supposed to work, given
this part of the proposal:
"A null-safe method invocation expression e1?.name(args) ... the type
of the result is the same as the type of e1.name(args). It is an
error if this is not a reference type."
Doesn't that mean that the compiler should reject the expression
More information about the coin-dev