Changes for TC52 3rd edition

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
===================================================================
--- docs/language/dartLangSpec.tex	(revision 44569)
+++ docs/language/dartLangSpec.tex	(working copy)
@@ -37,7 +37,7 @@
 A conforming  implementation of the Dart programming language must provide and support all the  APIs (libraries, types, functions, getters, setters, whether top-level, static, instance or local) mandated in this specification. 
 
 \LMHash{}
-A conforming implementation is permitted to provide additional APIs, but not additional syntax.
+A conforming implementation is permitted to provide additional APIs, but not additional syntax, except for experimental features in support of null-aware cascades and tear-offs that are likely to be introduced in the next revision of this specification.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Clever :)

[eernst, 2015/03/26 22:38:50]

I guess 'property extraction' covers more than intended, but 'tear-offs' might
require a definition since it is a new term in the specification.

 
 \section{Normative References}
 \LMLabel{ecmaNormativeReferences}
@@ -2349,6 +2349,8 @@
       literal;
       identifier;
       newExpression;
+      \NEW{} type `\#' (`{\escapegrammar .}' identifier)?;
+      \CONST{} type `\#' (`{\escapegrammar .}' identifier)?;

[Paul Berry, 2015/03/26 18:55:58]

What's the justification for having tear-offs of both the form "new type#" and
"const type#"?  I don't see any semantic difference between the two syntaxes.

[Lasse Reichstein Nielsen, 2015/03/26 19:18:57]

Ack, yes, forgot to comment on that.
If there is no difference between the two, I'd prefer to not have the const
version. It looks like the "const" means something, which it doesn't.

If "const Foo#bar" was a compile-time constant expression, it would make sense,
but I don't see any changes to the constant section.
Also, there is no reason to not make "new Foo#bar" a compile-time constant, and
in that case the const version should again be dropped.

Which also reminds me: MyClass.staticMethod is a compile time constant, should
MyClass#staticMethod (or getter/setter) also be constant?

[eernst, 2015/03/26 22:38:51]

Did you have to add the periods here to make the grammar parseable?  I don't see
them in earlier documentation about the tear-offs (e.g.,
https://github.com/gbracha/generalizedTearOffs/blob/master/proposal.md).

[gbracha, 2015/03/26 23:21:22]

You mean we haven't stated that a const T# is a constant constructor?

       constObjectExpression;
       `(' expression `)'
     .
@@ -3525,11 +3527,14 @@
 }
 
 \LMHash{}
-If $f$ is asynchronous then, when $f$ terminates, any open stream subscriptions associated with any asynchronous for loops  (\ref{asynchronousFor-in}) or yield-each statements  (\ref{yieldEach}) executing within $f$ are canceled.
+If $f$ is asynchronous then, when $f$ terminates, any open stream subscriptions associated with any asynchronous for loops  (\ref{asynchronousFor-in}) or yield-each statements  (\ref{yieldEach}) executing within $f$ are canceled, in the order of their nesting, innermost first.
 
 \rationale{Such streams may be left open by for loops that were escaped when an exception was thrown within them for example.
 }
 
+%\LMHash{}
+%When a stream is canceled, the implementation must wait for the cancelation future returned by \cd{cancell()} to complete before proceeding.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Uncomment?
Also maybe: "stream is canceled" -> "stream subscription associated with a
\code{yield*} or \code{await for} loop is canceled"

[gbracha, 2015/03/26 23:21:22]

The VM team has concerns with this. If it's absence is a bug, it has been there
since the initial version. I'm leaving as is until we are clear on that point.

+
 \LMHash{}
 If $f$ is marked \SYNC* (\ref{functions}), then a fresh instance $i$ implementing the built-in class \code{Iterable} is associated with the invocation and immediately returned.  
 
@@ -3775,12 +3780,30 @@
 \LMLabel{ordinaryInvocation}
 
 \LMHash{}
-An ordinary method invocation $i$ has the form 
+An ordinary method invocation can be {\em conditional} or {\em unconditional}.
 
+\LMHash{}
+Evaluation of a {\em conditional ordinary method invocation} $e$ of the form 
+
+\LMHash{}
+$o?.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$  
+
+\LMHash{}
+is equivalent to the evaluation of the expression  
+
+\LMHash{}
+$((x) => x == \NULL ? \NULL : x.im(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k}))(o)$. 

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

x.im -> x.m

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Does this correctly give static warnings if o.m does not have the correct type,
because "x" here is dynamic so x.m(...) would not give warnings if looking only
at the rewritten version.

Could it be written as:
  $((T x) => x == .....)(o)$
  where $T$ is the static type of $o$
? 

[Paul Berry, 2015/03/26 15:07:21]

Unfortunately Lasse's proposed rewrite would introduce an additional type check
in checked mode which I think would be confusing, since the user is going to
expect that the only difference between "?." and "." is the null check.  (It's
possible to construct programs that run in checked mode without throwing an
exception, but which nonetheless contain an expression whose runtime type is
unrelated to its static type).

I think the CL is ok as is, since line 3786 says that we're only rewriting
o?.m(...) for evaluation purposes, and line 3798 explicitly specifies the static
type of o?.m(...).

[gbracha, 2015/03/26 23:21:21]

Done.

[gbracha, 2015/03/26 23:21:23]

No, because checked mode would behave differently. Need to deal with warnings
separately. I have adjusted the text in 16.18 and 16.17.1 accordingly.

+
+\LMHash{}
+The static type of $e$ is the same as the static type of $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
+
+\LMHash{}
+An {\em unconditional ordinary method invocation} $i$ has the form 
+
 $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 \LMHash{}
-Evaluation of an ordinary method invocation $i$ of the form 
+Evaluation of an unconditional ordinary method invocation $i$ of the form 
 
 $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
 
@@ -3876,6 +3899,12 @@
 \LMHash{}
 A cascaded method invocation expression of the form {\em e..suffix} is equivalent to the expression \code{(t)\{t.{\em suffix}; \RETURN{} t;\}($e$)}.
 
+\rationale{
+With the introduction of null-aware conditional assignable expressions (\ref{assignableExpressions}), it would make sense to extend cascades with a null-aware conditional form as well. One might define {\em e?..suffix}  to be equivalent to the expression \code{(t)\{t?.{\em suffix}; \RETURN{} t;\}($e$)}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Makes sense. We have cascades so you can write x..foo..bar; instead of
x.foo;x.bar;. Would be sad to have to go back to x?.foo;x?.bar; because of lack
of x?..foo?..bar

[eernst, 2015/03/26 22:38:51]

Having x?..foo?..bar it's natural to consider x?..foo..bar and x..foo?..bar. 
Only the "?-everywhere" and "?-nowhere" variants seem to make sense, because
either the ? is "unused", or the cascade section with no ? will unconditionally
fail.  So maybe the syntax should enforce that only everywhere/nowhere in
possible.

+
+The present specification has not added such a construct, in the interests of simplicity and rapid language evolution. However, Dart implementations may experiment with such constructs, as noted in section \ref{ecmaConformance}.
+}
+
 \subsubsection{Super Invocation}
 \LMLabel{superInvocation}
 
@@ -3946,21 +3975,32 @@
 \LMLabel{propertyExtraction}
 
 \LMHash{}
-{\em Property extraction} allows for a member of an object to be concisely extracted from the object.
+{\em Property extraction} allows for a member or constructor to be accessed as a property rather than a function.
 A property extraction can be either:
 \begin{enumerate}
-\item A {\em closurization} (\ref{closurization}) which allows a method to be treated as if it were a getter for a function valued object. Or
+\item A {\em closurization} which converts a method or constructor into a closure. Or
 \item A {\em getter invocation} which returns the result of invoking of a getter method.
 \end{enumerate}
 
 \LMHash{}
+Property extraction takes several syntactic forms: $e.m$ (\ref{getterAccessAndMethodExtraction}), $\SUPER.m$ (\ref{superGetterAccessAndMethodClosurization}), $e\#m$ (\ref{generalClosurization}), $\NEW{}$ $T\#m$ (\ref{namedConstructorExtraction}), $\NEW{}$ $T\#$ (\ref{anonymousConstructorExtraction}) and $\SUPER\#m$ (\ref{generalSuperPropertyExtraction}), where $e$ is an expression, $m$ is an identifier optionally followed by an equal sign and $T$ is a type.

[Paul Berry, 2015/03/26 15:07:21]

As I mentioned on line 3704, I think the syntactic forms "e?.m" and "super?.m"
also need to be covered, so that warnings defined in this section will apply to
expressions of these forms.

[gbracha, 2015/03/26 23:21:22]

super?.m makes no sense; I've altered the grammar to ban that. e?.m is now
covered.

+
+\subsubsection{Getter Access and Method Extraction}
+\LMLabel{getterAccessAndMethodExtraction}
+
+\LMHash{}
 Evaluation of a property extraction $i$ of the form $e.m$ proceeds as follows:
 
 \LMHash{}
-First, the expression $e$ is evaluated to an object $o$. Let $f$ be the result of looking up (\ref{methodLookup}) method  (\ref{instanceMethods}) $m$ in $o$ with respect to the current library $L$.  If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $m$ is a method that forwards (\ref{functionDeclarations}) to a static method,  method lookup fails. If method lookup succeeds and $f$ is a concrete method then $i$ evaluates to the closurization of $o.m$.  
+First, the expression $e$ is evaluated to an object $o$. Let $f$ be the result of looking up (\ref{methodLookup}) method  (\ref{instanceMethods}) $m$ in $o$ with respect to the current library $L$.  If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards (\ref{functionDeclarations}) to a static method,  method lookup fails. If method lookup succeeds then $i$ evaluates to the closurization of method $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
 
+\commentary {
+Note that $f$ is never an abstract method, because method lookup skips abstract methods. Hence, if $m$ refers to an abstract method, we will continue to the next step. However, since methods and getters never override each other, getter lookup will necessarily fail as well, and \cd{noSuchMethod()} will ultimately be invoked. The regrettable implication is that the error will refer to a missing getter rather than an attempt to closurize an abstract method.
+}
+
 \LMHash{}
-Otherwise, $i$ is a getter invocation, and the getter function (\ref{getters}) $m$ is looked up (\ref{getterAndSetterLookup}) in $o$  with respect to $L$. If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $m$ is a getter that forwards  to a static getter,  getter lookup fails. Otherwise, the body of $m$ is executed with \THIS{} bound to $o$.  The value of $i$ is the result returned by the call to the getter function. 
+Otherwise, $i$ is a getter invocation.  Let $f$ be the result of looking up
+(\ref{getterAndSetterLookup}) getter (\ref{getters}) $m$ in $o$  with respect to $L$. If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $f$ is a getter that forwards  to a static getter,  getter lookup fails. Otherwise, the body of $f$ is executed with \THIS{} bound to $o$.  The value of $i$ is the result returned by the call to the getter function. 
 
 \LMHash{}
 If the getter lookup has failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
@@ -3972,10 +4012,10 @@
 \end{itemize}
 Then the method \code{noSuchMethod()} is looked up in $o$ and invoked  with argument $im$, and the result of this invocation is the result of evaluating $i$. However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on $o$ with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
 \begin{itemize}
-\item  \code{im.isMethod} evaluates to \code{\TRUE{}}.
-\item  \code{im.memberName} evaluates to \code{noSuchMethod}.
-\item \code{im.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
-\item \code{im.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
+\item  \code{im'.isMethod} evaluates to \code{\TRUE{}}.
+\item  \code{im'.memberName} evaluates to \code{noSuchMethod}.
+\item \code{im'.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
+\item \code{im'.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
 \end{itemize}
 
 and the result of this latter invocation is the result of evaluating $i$.
@@ -3996,24 +4036,27 @@
 \end{itemize}
 
 \LMHash{}
-If $i$ is a getter invocation, the static type of $i$ is:
+The static type of $i$ is:
 \begin{itemize}
-\item The declared return type of $T.m$, if $T.m$ exists.
-\item The declared return type of $m$, if  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ has a static method or getter named $m$.
+\item The declared return type of $T.m$, if $T$  has an accessible instance getter named $m$.
+\item The declared return type of $m$, if  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static getter named $m$.
+\item The static type of function $T.m$ if $T$ has an accessible instance method named $m$.
+\item The static type of function $m$, if  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static method named $m$.
 \item  The type \DYNAMIC{} otherwise.  
 \end{itemize}
 
-\LMHash{}
-If $i$ is a closurization, its static type is as described in section \ref{closurization}.
 
+\subsubsection{Super Getter Access and Method Closurization}
+\LMLabel{superGetterAccessAndMethodClosurization}
+
 \LMHash{}
 Evaluation of a property extraction $i$ of the form $\SUPER.m$ proceeds as follows:
 
 \LMHash{}
- Let $S$ be the superclass of the immediately enclosing class. Let $f$ be the result of looking up method $m$ in $S$ with respect to the current library $L$.  If $f$ is a concrete method then $i$ evaluates to the closurization of $\SUPER.m$ with respect to superclass $S$(\ref{closurization}).  
+ Let $S$ be the superclass of the immediately enclosing class. Let $f$ be the result of looking up method $m$ in $S$ with respect to the current library $L$.  If method lookup succeeds then $i$ evaluates to the closurization of method $f$ with respect to superclass $S$ (\ref{superClosurization}).  
  
 \LMHash{}
- Otherwise, $i$ is a getter invocation and the getter function $m$ is looked up in $S$  with respect to $L$, and its body is executed with \THIS{} bound to the current value of  \THIS{}.  The value of $i$ is the result returned by the call to the getter function. 
+ Otherwise, $i$ is a getter invocation.  Let $f$ be the result of  looking up getter $m$ in $S$  with respect to $L$.  The body of $f$  is executed with \THIS{} bound to the current value of  \THIS{}.  The value of $i$ is the result returned by the call to the getter function. 
 
 \LMHash{}
 If the getter lookup has failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
@@ -4025,34 +4068,166 @@
 \end{itemize}
 Then the method \code{noSuchMethod()} is looked up in $S$ and invoked  with argument $im$, and the result of this invocation is the result of evaluating $i$. However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on \THIS{} with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
 \begin{itemize}
-\item  \code{im.isMethod} evaluates to \code{\TRUE{}}.
-\item  \code{im.memberName} evaluates to \code{noSuchMethod}.
-\item \code{im.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
+\item  \code{im'.isMethod} evaluates to \code{\TRUE{}}.
+\item  \code{im'.memberName} evaluates to \code{noSuchMethod}.
+\item \code{im'.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
+\item \code{im'.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
+\end{itemize}
+and the result of this latter invocation is the result of evaluating $i$.
+
+\LMHash{}
+It is a static type warning if $S$ does not have an accessible instance method or getter named $m$.  
+
+The static type of $i$ is:
+\begin{itemize}
+\item The declared return type of $S.m$, if $S$ has an accessible instance getter named $m$.
+\item The static type of function $S.m$ if $S$ has an accessible instance method named $m$.
+\item The type  \DYNAMIC{} otherwise. 
+\end{itemize}
+
+
+\subsubsection{General Closurization}
+\LMLabel{generalClosurization}
+
+\LMHash{}
+Evaluation of a property extraction $i$ of the form $e\#m$ proceeds as follows:
+
+\LMHash{}
+First, the expression $e$ is evaluated to an object $o$. Let $f$ be the result of looking up method $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static method, method lookup fails. If method lookup succeeds then $i$ evaluates to the closurization of method $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
+ 
+\LMHash{}
+ Otherwise, let $f$ be the result of looking up getter $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static getter, getter lookup fails. If getter lookup succeeds then $i$ evaluates to the closurization of getter $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
+ 
+ \LMHash{}
+ Otherwise, let $f$ be the result of looking up setter $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static setter, setter lookup fails. If setter lookup succeeds then $i$ evaluates to the closurization of setter $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

So we technically go through the previous two lookups for the the name "m=",
even if we know syntactically that they can't succeed?
How about splitting on that at the top:
 if m is not a setter name then
  - method lookup
  - getter lookup
 else if m is a setter name then
  - setter lookup
?
I think I'd find that less confusing.

[sra1, 2015/03/26 19:41:38]

It seems that this would be simpler if the closurization site made explicit
whether a tear-off getter, setter or method was required.

e#foo
  - a field access or tear off method

e#get foo
  - Closurizer the getter. Always returns a function taking zero arguments.
Closurizes the implicit getter of a field or the closurizing getter of a method.


e#set foo
  - Closurizes the setter.  Always returns a function taking exactly one
argument.

[gbracha, 2015/03/26 23:21:22]

Yes, I think splitting it makes a lot of sense, for this and other reasons.
Done.

+ 
+
+\LMHash{}
+Otherwise,  a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
+\begin{itemize}
+\item  If $m$ is a setter name, \code{im.isSetter} evaluates to \code{\TRUE{}}; otherwise \code{im.isMethod} evaluates to \code{\TRUE{}}

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

I still think this is dangerously wrong, and must not be released in its current
form.

A noSuchMethod implementation seeing "im.isMethod" will assume that it is a
method call and may emulate the call with zero arguments, which is wrong.
It would actually want to return a function to correctly emulate the extraction.

Similarly, seeing "isSetter" as true but with zero positional parameters is
breaking the invariant on Invocation. The documentation of Invocation.isSetter
says:
   * Whether the invocation was a setter call.
   *
   * If so, [arguments] has exactly one positonal argument,
   * and [namedArguments] is empty.
The invocation object created here is simply invalid, and should not be created
or be passed to any existing code.


I'd actually prefer to not go through the object's noSuchMethod at all, and just
throw a NoSuchMethodError directly until we can find a way to make it
interceptable without being wrong. The current approach should *not* be
launched, it's just too broken.

[sra1, 2015/03/26 19:41:38]

I think this would also be fixed by e#foo / e#get foo / e#set foo.

[Lasse Reichstein Nielsen, 2015/03/26 20:23:23]

I don't see how that would change anything. There is no reasonable way to send
an Invocation to a noSuchMethod method corresponding to extracting a setter,
whether it's written e#foo= or e#set foo.

[gbracha, 2015/03/26 23:21:22]

Good point. Indeed, existing tear-offs using the e.m syntax already have this
problem, though no one has noticed so far. Long term, I think we need to extend
noSuchMethod with an #isTearOff flag.  I would not change the e.m tear-off
behavior, but e#m would then set the flag. Presumably, no working code would
notice the difference (I'll neglect any crazies who catch NoSuchMethodError).
Yes, but if I split the cases I could have it pass a dummy argument. But the
point above remains.

The documentation of Invocation.isSetter
Well, we launched the same broken semantics years ago :-) But I agree.

[Lasse Reichstein Nielsen, 2015/03/27 07:03:04]

The existing extraction works because of the correspondence between a function
and a function-typed getter - if can try to "get" or "call" a name, and the
noSuchMethod can distinguish the two and simulate its choice of field or method.
You could even have said that a method introduces a synthetic getter which
returns the extracted function, so "o.foo" accesses would always use a getter.

It breaks down only for the new extraction of getters and setters because we get
a third way to access a name, and Invocation has no way to represent that. An
existing noSuchMethod implementation cannot correctly simulate a getter because
extracting a getter is a completely new thing (but extracting a function isn't).

In this way, o#foo is actually slightly worse than the existing tear-off because
it does does not treat function-typed getters and methods the same - the former
returns a function that must be called to get the value, the latter just returns
the value. That's OK because the language has always been saying that a function
typed getter and a function are quite different (one can't override the other).

Sadly, even if we add an isTearOff flag to the Invocation, it will still make
existing code behave incorrectly if it sees such an invocation because it
doesn't check for that flag or implement it. We may want it anyway (it's not
*breaking* because no existing program will stop working, but existing libraries
may not be compatible with new code).

+\item  \code{im.memberName} evaluates to \code{'m'}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

This looks like it evaluates to a string, but it should evaluate to a symbol.
Either:
  evaluates to the symbol \code{m}.
or 
  evaluates to \code{\#m}.
?

[gbracha, 2015/03/26 23:21:22]

A bug that has been lying dormant for a while. Fixed in all locations.

+\item \code{im.positionalArguments} evaluates to the value of \code{\CONST{} []}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Are we requiring "const []" in other places too? Otherwise I think it might be
overspecifying since it is detectable whether the value really is const [] or
some othe empty fixed-length array, and you don't need it to be that specific
object.

[eernst, 2015/03/26 22:38:50]

Why not \code{\CONST{} <Object>[]}, such that List<dynamic> instances are not
created unless this is unavoidable?  A similar argument would call for
\code{\CONST <Object>\{\}} below.

[gbracha, 2015/03/26 23:21:22]

We have been doing this in similar situations with method lookup (e.g., const
{}). 

 \item \code{im.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.
 \end{itemize}
-
+Then the method \code{noSuchMethod()} is looked up in $o$ and invoked  with argument $im$, and the result of this invocation is the result of evaluating $i$. However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on $o$ with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
+\begin{itemize}
+\item  \code{im'.isMethod} evaluates to \code{\TRUE{}}.
+\item  \code{im'.memberName} evaluates to \code{noSuchMethod}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Symbol #noSuchMethod ?

[gbracha, 2015/03/26 23:21:22]

Done everywhere in response to previous comment.

+\item \code{im'.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
+\item \code{im'.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.

[eernst, 2015/03/26 22:38:50]

Could again be <Object>[$im$] and \CONST <Object>\{\}.

+\end{itemize}
 and the result of this latter invocation is the result of evaluating $i$.
 
 \LMHash{}
-It is a static type warning if $S$ does not have a method or getter named $m$.  If $i$ is a getter invocation, the static type of $i$ is the declared return type of $S.m$, if $S.m$ exists and  \DYNAMIC{} otherwise. If $i$ is a closurization, its static type is as described in section \ref{closurization}.
+It is a compile-time error if $e$ is a prefix object (\ref{imports}) and $m$ refers to a type or a member of class \cd{Object}.
 
+\commentary{
+This restriction is in line with other limitations on the use of prefixes as objects. The only permitted uses of $p\#m$ are closurizing top level methods and getters imported via the prefix $p$. Top level methods are directly available by their qualified names: $p.m$. However, getters and setters are not, and allowing their closurization is the whole point of the $e\#m$ syntax.
+}
 
-\subsubsection{Closurization}
-\LMLabel{closurization}
+\LMHash{}
+Let $T$ be the static type of $e$. It is a static type warning if $T$ does not have an accessible instance method or getter named $m$ unless either:

[Paul Berry, 2015/03/26 18:55:58]

It seems inconsistent that on line 4102 we allow e#m to refer to a setter named
m (if there is no function or getter named m), but here we don't allow for it.

I think we need to say "It is a static type warning if $T$ does not have an
accessible instance method, getter, or setter named m unless either..."

So that code like the following will be warning-free:

class C {
  void set s(int value) { ... }
}
f(C c) => c#s=;

+\begin{itemize}
+\item $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant proxy defined in \cd{dart:core}. Or

[Paul Berry, 2015/03/26 18:55:58]

Nit: when this text appears elsewhere in the spec, "proxy" is notated as
"@proxy".

+\item $T$ is \cd{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static method or getter named $m$.

[Paul Berry, 2015/03/26 18:55:58]

Similarly, "or setter" should be added here.

+\end{itemize}
 
+The static type of $i$ is:
+\begin{itemize}
+\item The static type of function $T.m$, if $T$ has an accessible instance member named $m$.
+\item The static type of function $T.m$, if $T$ is \cd{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static member or constructor named $m$.
+\item The type  \DYNAMIC{} otherwise. 
+\end{itemize}

[Paul Berry, 2015/03/26 18:55:58]

Consider adding some non-normative explanatory text to clarify that in the case
where $T$ has an accessible instance member that is a getter or a setter, the
static type of $i$ is the type of the getter or setter function.

(I missed this subtlety on the first several readings, and assumed that you'd
simply forgotten to cover these cases.)

+
+\subsubsection{Named Constructor Extraction}
+\LMLabel{namedConstructorExtraction}
+
 \LMHash{}
-The {\em closurization of $o.m$} is defined to be equivalent to:
+Evaluation of a property extraction $i$ of the form \NEW{} $T\#m$ or \CONST{} $T\#m$ proceeds as follows:

[Paul Berry, 2015/03/26 18:55:58]

This is inconsistent with line 2352, where the constructs that are added to the
grammar contain '.', e.g. "new T#.m" and "const T#.m".

 
+\LMHash{}
+If $T$ is a malformed type (\ref{staticTypes}), a dynamic error occurs. If $T$ is a deferred type with prefix $p$, then if $p$ has not been successfully loaded, a dynamic error occurs. If $T$ does not denote a class, a dynamic error occurs. In checked mode, if $T$ or any of its superclasses is malbounded a dynamic error occurs. Otherwise, if the type $T$ does not declare an accessible named constructor $f$ with name $m$, a \cd{NoSuchMethodError} is thrown. Otherwise, $i$ evaluates to the closurization of constructor $f$ of type $T$ (\ref{namedConstructorClosurization}).
+
+\commentary{Note that if $T$ is malformed or malbounded, a static warning occurs, as always.}
+
+\LMHash{}
+The static type of $i$ is the type of the constructor function, if $T$ denotes a class in the surrounding scope with an accessible constructor $f$ named $m$. Otherwise the static type of $i$ is \DYNAMIC{}.

[Paul Berry, 2015/03/26 18:55:58]

"$f$" can be removed, since nothing refers to it.

+
+\subsubsection{Anonymous Constructor Extraction}
+\LMLabel{anonymousConstructorExtraction}
+
+\LMHash{}
+Evaluation of a property extraction $i$ of the form \NEW{} $T\#$ or \CONST{} $T\#$ proceeds as follows:
+
+\LMHash{}
+If $T$ is a malformed type (\ref{staticTypes}), a dynamic error occurs. If $T$ is a deferred type with prefix $p$, then if $p$ has not been successfully loaded, a dynamic error occurs. If $T$ does not denote a class, a dynamic error occurs. In checked mode, if $T$ or any of its superclasses is malbounded a dynamic error occurs. Otherwise, if the type $T$ does not declare an accessible anonymous constructor, a \cd{NoSuchMethodError} is thrown. Otherwise, $i$ evaluates to the closurization of the anonymous constructor of type $T$ (\ref{anonymousConstructorClosurization}).
+
+\commentary{Again, note that if $T$ is malformed or malbounded, existing rules ensure that a static warning occurs. This also means that $x\#$ where $x$ is not a type will always give a static warning.}

[Paul Berry, 2015/03/26 18:55:58]

I think you mean "This also means that \NEW{} $x\#$ or \CONST{} $x\#$ where $x$
is not a type will always give a static warning."

+
+\LMHash{}
+The static type of $i$ is the type of the constructor function $T()$, if $T$ denotes a class in the surrounding scope with an anonymous constructor $T()$. Otherwise the static type of $i$ is \DYNAMIC{}.
+
+\subsubsection{General Super Property Extraction}
+\LMLabel{generalSuperPropertyExtraction}
+
+
+\LMHash{}
+Evaluation of a property extraction $i$ of the form \SUPER$\#m$ proceeds as follows:
+
+Let $S$ be the superclass of the immediately enclosing class. Let $f$ be the result of looking up method $m$ in $S$ with respect to the current library $L$. If method lookup succeeds then $i$ evaluates to the closurization of method $m$ with respect to superclass $S$ (\ref{superClosurization}).
+
+\LMHash{}
+ Otherwise, let $f$ be the result of looking up getter $m$ in $S$ with respect to the current library $L$.  If getter lookup succeeds then $i$ evaluates to the closurization of getter $f$ with respect to superclass $S$ (\ref{superClosurization}).  
+ 
+ \LMHash{}
+ Otherwise, let $f$ be the result of looking up setter $m$ in $S$ with respect to the current library $L$. If setter lookup succeeds then $i$ evaluates to the closurization of setter $f$  with respect to superclass $S$  (\ref{superClosurization}).  
+ 
+
+\LMHash{}
+Otherwise,  a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
 \begin{itemize}
+\item  If $m$ is a setter name, \code{im.isSetter} evaluates to \code{\TRUE{}}; otherwise \code{im.isMethod} evaluates to \code{\TRUE{}}

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Same comment as above: Just throw a NoSuchMethodError directly instead of
sending incorrect/broken information to noSuchMethod.

[gbracha, 2015/03/26 23:21:21]

Done.

+\item  \code{im.memberName} evaluates to \code{'m'}.
+\item \code{im.positionalArguments} evaluates to the value of \code{\CONST{} []}.
+\item \code{im.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.

[eernst, 2015/03/26 22:38:50]

Again we could have <Object>[] and <Object>{}.

+\end{itemize}
+Then the method \code{noSuchMethod()} is looked up in $S$ and invoked  with argument $im$, and the result of this invocation is the result of evaluating $i$. However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on \THIS{} with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
+\begin{itemize}
+\item  \code{$im'$.isMethod} evaluates to \code{\TRUE{}}.
+\item  \code{$im'$.memberName} evaluates to \code{noSuchMethod}.
+\item \code{$im'$.positionalArguments} evaluates to an immutable list whose sole element is  $im$.
+\item \code{$im'$.namedArguments} evaluates to the value of \code{\CONST{} \{\}}.

[eernst, 2015/03/26 22:38:51]

<Object>{}.

+\end{itemize}
+and the result of this latter invocation is the result of evaluating $i$.
 
+\LMHash{}
+It is a static type warning if $S$ does not have an accessible instance member named $m$.
+
+\LMHash{}
+The static type of $i$ is the static type of the function $S.m$,  if $S$ has an accessible instance member named $m$. Otherwise the static type of $i$ is \DYNAMIC{}.
+
+
+
+\subsubsection{Ordinary Member Closurization}
+\LMLabel{ordinaryMemberClosurization}
+
+
+\LMHash{}
+Let $o$ be an object, and let $u$ be a fresh final variable bound to $o$.
+The {\em closurization of method $f$ on object $o$} is defined to be equivalent to:
+\begin{itemize}
+\item $(a) \{\RETURN{}$ $u$ $m$ $a;$\} if $f$ is named $m$ and $m$ is one of  \code{$<$, $>$, $<$=, $>$=, ==,  -, +, /, \~{}/, *, \%, $|$, \^{}, \&, $<<$, $>>$} (this precludes closurization of unary -).
+\item $() \{\RETURN{}$ \~{} $u;$\} if $f$ is named \~{}.
+\item $(a) \{\RETURN{}$ $u[a];$\} if $f$ is named $[]$.
+\item $(a, b) \{\RETURN{}$ $u[a] = b;$\} if $f$ is named $[]=$.
 \item  
 \begin{dartCode}
 $(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
   \RETURN{} $ u.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
 \} 
 \end{dartCode}
-
-if $m$ has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
 \item 
 \begin{dartCode}
 $(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
@@ -4060,15 +4235,19 @@
 \}
 \end{dartCode}
 
-if $m$ has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
 \end{itemize}
 
-where $u$ is a fresh final variable bound to $o$, except that:
-\begin{enumerate}
-\item  Iff  \code{identical($o_1, o_2$)}  then \cd{$o_1.m$ == $o_2.m$}.
-\item The static type of the property extraction is the static type of function $T.m$, where $T$ is the static type of $e$, if $T.m$ is defined. Otherwise the static type of $e.m$ is \DYNAMIC{}.
-\end{enumerate}
+\LMHash{}
+Except that iff  \code{identical($o_1, o_2$)}  then  \cd{$o_1\#m$ == $o_2\#m$},  \cd{$o_1.m$ == $o_2.m$}, \cd{$o_1\#m$ == $o_2.m$} and  \cd{$o_1.m$ == $o_2\#m$}.
+%\item The static type of the property extraction is the static type of function $T.m$, where $T$ is the static type of $e$, if $T.m$ is defined. Otherwise the static type of $e.m$ is \DYNAMIC{}.

[eernst, 2015/03/26 22:38:51]

Why is this commented out?

 
+\LMHash{}
+The {\em closurization of getter $f$ on object $o$} is defined to be equivalent to \cd{()\{\RETURN{} u.m;\}} if $f$ is named $m$, except that iff  \code{identical($o_1, o_2$)} then  \cd{$o_1\#m$ == $o_2\#m$}.
+
+\LMHash{}
+The {\em closurization of setter $f$ on object $o$} is defined to be equivalent to \cd{(a)\{\RETURN{} u.m = a;\}} if $f$ is named $m=$, except that iff  \code{identical($o_1, o_2$)} then \cd{$o_1\#m=$ == $o_2\#m=$}.
+
 \commentary{
 There is no guarantee that \cd{identical($o_1.m, o_2.m$)}. Dart implementations are not required to canonicalize these or any other closures.
 }
@@ -4078,52 +4257,114 @@
 The special treatment of equality in this case facilitates the use of extracted property functions in APIs where callbacks such as event listeners must often be registered and later unregistered. A common example is the DOM API in web browsers.
 }
 
+\commentary {
+Observations:
 
+One cannot closurize a constructor, getter or a setter via the dot based syntax. One must use the \# based form. One can tell whether one implemented a property via a method or via a field/getter, which means that one has to plan ahead as to what construct to use, and that choice is reflected in the interface of the class.
+}
 
 
-\commentary{Observations:
-\begin{enumerate}
-\item One cannot closurize a getter or a setter.
-\item One can tell whether one implemented a property via a method or via a field/getter, which means that one has to plan ahead as to what construct to use, and that choice is reflected in the interface of the class.
-\end{enumerate}
-} 
 
+\subsubsection{Named Constructor Closurization}
+\LMLabel{namedConstructorClosurization}
 
- 
 \LMHash{}
-The closurization of $\SUPER{}.m$ with respect to superclass $S$ is defined to be equivalent to:
-
+The {\em closurization of constructor $f$ of type $T$} is defined to be equivalent to:
 \begin{itemize}
- %\item $(r_1, \ldots, r_n)\{\RETURN{}$ $o.m(r_1, \ldots, r_n);\}$ if $m$ has only required parameters $r_1, \ldots r_n$.
-%\item $(r_1, \ldots, r_n, rest)\{return$  $o.m(r_1, \ldots, r_n, rest);\}$ if $m$ has required parameters $r_1, \ldots r_n$, and a rest parameter $rest$.
-%\item
 \item  
 \begin{dartCode}
-$(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$\{
-   \RETURN{} \SUPER{}$.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k)$;
-\}
+$(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
+  \RETURN{} \NEW{} $T.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
+\} 
 \end{dartCode}
 
-if $m$ has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+if $f$ is a named constructor with name $m$ that has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
 \item 
 \begin{dartCode}
 $(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
-   \RETURN{} \SUPER{}$.m(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
+  \RETURN{} \NEW{} $T.m(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
+\}
+\end{dartCode}
+
+if $f$ is a named constructor with name $m$ that has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+\end{itemize}
+
+\LMHash{}
+Except that iff  \code{identical($T_1, T_2$)}  then  \cd{\NEW{} $T_1\#m$ == \NEW{} $T_2\#m$}.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

The identical(T_1, T_2) looks odd when you are comparing types, since they are
not being used as values in the T_1#m / T_2#m syntax. How about: 
  For any type T, new T#m == new T#m (that is, creating a closurization of the
same constructor twice gives functions that are equal to each other).

[gbracha, 2015/03/26 23:21:21]

Then I have to exclude parameterized types somehow. Leaving as is.

+
+\commentary{ 
+The above implies that for non-parameterized types, one can rely on the equality of closures resulting from closurization on the ``same'' type. For parameterized types, one cannot, since there is no requirement to canonicalize them.
+}
+
+\subsubsection{Anonymous Constructor Closurization}
+\LMLabel{anonymousConstructorClosurization}
+
+\LMHash{}
+The {\em closurization of anonymous constructor $f$ of type $T$} is defined to be equivalent to:
+\begin{itemize}
+\item  
+\begin{dartCode}
+$(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
+  \RETURN{} \NEW{} $T(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
 \} 
 \end{dartCode}
 
-if $m$ has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+if $f$ is an anonymous constructor that has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+\item 
+\begin{dartCode}
+$(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
+  \RETURN{} \NEW{} $T(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
+\}
+\end{dartCode}
+
+if $f$ is an anonymous constructor that has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
 \end{itemize}
 
 \LMHash{}
-Except that:
-\begin{enumerate}
-\item  iff  \code{identical($o_1, o_2$)}  then \cd{$o_1.m$ == $o_2.m$}.
+Except that iff  \code{identical($T_1, T_2$)}  then  \cd{\NEW{} $T_1\#$ == \NEW{} $T_2\#$}.
+
+
+\subsubsection{Super Closurization}
+\LMLabel{superClosurization}
+
+\LMHash{}
+The {\em closurization of method $f$ with respect to superclass $S$} is defined to be equivalent to:
+
+\LMHash{}
+\begin{itemize}
+\item $(a) \{\RETURN{}$ \SUPER{} $m$ $a;$\} if $f$ is named $m$ and $m$ is one of  \code{$<$, $>$, $<$=, $>$=, ==,  -, +, /, \~{}/, *, \%, $|$, \^{}, \&, $<<$, $>>$}.
+\item $() \{\RETURN{}$ \~{}\SUPER;\} if $f$ is named \~{}.
+\item $(a) \{\RETURN{}$ $\SUPER[a];$\} if $f$ is named $[]$.
+\item $(a, b) \{\RETURN{}$ $\SUPER[a] = b;$\} if $f$ is named $[]=$.
+\item  
+\begin{dartCode}
+$(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
+  \RETURN{} \SUPER$.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
+\} 
+\end{dartCode}
+if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
 \item 
-The static type of the property extraction is the static type of the method $S.m$,  if $S.m$ is defined. Otherwise the static type of $\SUPER{}.m$ is \DYNAMIC{}.
-\end{enumerate}
+\begin{dartCode}
+$(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
+  \RETURN{} \SUPER$.m(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
+\}
+\end{dartCode}
 
+if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and optional positional parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
+\end{itemize}
 
+\LMHash{}
+Except that iff two closurizations were created by code declared in the same class with identical bindings of \THIS{} then  \cd{\SUPER$_1\#m$ == \SUPER$_2\#m$},  \cd{\SUPER$_1.m$ == \SUPER$_2.m$}, \cd{\SUPER$_1\#m$ == \SUPER$_2.m$} and  \cd{\SUPER$_1.m$ == \SUPER$_2\#m$}.
+
+
+\LMHash{}
+The {\em closurization of getter $f$  with respect to superclass $S$} is defined to be equivalent to \cd{()\{\RETURN{} \SUPER.m;\}} if $f$ is named $m$, except that iff two closurizations were created by code declared in the same class with identical bindings of \THIS{} then  \cd{\SUPER$_1\#m$ == \SUPER$_2\#m$}.
+
+\LMHash{}
+The {\em closurization of setter $f$  with respect to superclass $S$} is defined to be equivalent to \cd{(a)\{\RETURN{} \SUPER.m = a;\}} if $f$ is named $m=$, except that iff two closurizations were created by code declared in the same class with identical bindings of \THIS{} then \cd{\SUPER$_1\#m=$ == \SUPER$_2\#m=$}.
+
+
+
 \subsection{ Assignment}
 \LMLabel{assignment}
 
@@ -4174,6 +4415,9 @@
 It is a static type warning if the static type of $e$ may not be assigned to the static type of $v$. The static type of the expression $v$ \code{=} $e$ is the static type of $e$.
 
 \LMHash{}
+Evaluation of an assignment $a$ of the form $e_1?.v$ \code{=} $e_2$ is equivalent to the evaluation of the expression $((x) => x == \NULL? \NULL: x.v = e_2)(e_1)$. The static type of $a$ is the static type of $e_2$. 

[eernst, 2015/03/26 22:38:50]

It might be an error-prone choice to let $e_2$ be evaluated _zero_ times when
the value of $e_1$ is null.  Would it make sense to say that, compared to the
corresponding null-agnostic constructs, null-aware constructs do not change the
number of times subexpressions are evaluated, they just prevent lookups on null?

[Lasse Reichstein Nielsen, 2015/03/27 07:14:45]

The ?? operator is definitely short-circuit: (e1 ?? e2) will not evaluate e2 if
e1 evaluates to a non-null value. It's like JavaScript (e1 || e2).
That makes ??= also short-circuit.

For e1?.selector(e2) I would *not* expect e2 to be evaluated if selector isn't
called. The '?' guards the entire expression. So again, I think the guarding
should affect which expressions are evaluated, and I would be surprised if it
didn't.
Example:
  foo?.addFeature(new Feature(id: counter++))
If I'm not adding anything, I don't want to increment my counter.

So, the only one I may have doubts about is  e1.foo ?= e2.
If e1 is null, would I expect it to evaluate e2? I'm split on that.
Since assignment returns the value, you can have cases like:
  x = o?.bar = 42
and in that case you might want x to be 42.
On the other hand, it's inconsistent with the other cases, which counts against
it, and other null-aware expressions also have a value, so is this different
from:
  x = o?.setBar(42)
which sets x to null?

I think I lean slightly towards not evaluating the expression, making o?.bar = e
and o?.setBar(e) work the same way.

[eernst, 2015/03/27 08:44:03]

For (e1 || e2), the rationale for the short-circuit semantics could be "skip the
evaluation of subexpressions whose value cannot affect the value of the
expression as a whole" plus "evaluation proceeds from left to right".  

The same rationale doesn't quite work for (e1 ?? e2), but we could have "e2 is a
backup for e1, to be used only if necessary".  For e1?.selector(e2), we could
have "call off the entire action if e1 'is not present'", again not quite the
same.  Finally, with `v ?= e` we could have "call off the assignment if 'v _is_
already present'".  It seems that there is an interesting wealth of rationales
around.  ;)

One overarching principle that we could apply is: "Avoid the evaluation of
subexpressions as often as possible", in which case `v ?= e` should not evaluate
and return the value of `e` when `v != null`, but it could pass on the value of
`v` to the enclosing expression (just like other assignment expressions).

[Lasse Reichstein Nielsen, 2015/03/27 15:42:09]

We don't actually have "v ?= e", only "o?.p = e" which should call the setter p=
if o is not null (or did you mean "v ??= e"?).

It is true that there can be different perspectives. Mine is mostly as a "null
guard", and everything being guarded should be skipped if the guard is null (or
for '??', if it is not null). It's a shorthand for something with "x == null ?
... : ...".

The ?? operator exists in C# (and in Groovy as he Elvis operator), and it is
short-circuit there. It should be short-circuit in Dart too.

It seems that Groovy's safe navigation operator does evaluate arguments before
not calling a function, so that's a different behavior. C# is getting safe
navigation operators (?.foo, ?.coo(), ?[..]), but I can't find their spec. From
the examples I've seen I'd expect the ?.foo(args) to not evaluate args. I'll see
if I can find an implementation.

Groovy a.?x=print(42) also prints 42 if a is null.
At least they are consistent (but the language doesn't seem to have a
specification that actually specifies anything).

[eernst, 2015/04/07 10:44:49]

Sorry, I meant "v ??= e".

I think the most intuitive semantics (having had this in the back of my mind
today ;) is based on an "ok, then drop it" rationale: As soon as a null is
encountered, no more actions take place.

Assigning something to a variable _unless_ it is _non-null_ is an anomaly here. 
You might expect that only non-null values could be assigned to a formerly null
valued variable, but you can't undo the side-effects (e.g., print(42)) when you
discover that the returned value is null. So that operation probably doesn't
have a rationale.  ;-)

+
+\LMHash{}
 Evaluation of an assignment of the form $e_1.v$ \code{=} $e_2$ proceeds as follows:
 
 \LMHash{}
@@ -4233,10 +4477,18 @@
 \LMLabel{compoundAssignment}
 
 \LMHash{}
-A compound assignment of the form $v$ $op\code{=} e$ is equivalent to $v \code{=} v$ $op$ $e$. A compound assignment of the form $C.v$ $op \code{=} e$ is equivalent to $C.v \code{=} C.v$ $op$ $e$. A compound assignment of the form $e_1.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. A compound assignment of the form  $e_1[e_2]$ $op\code{=} e_3$ is equivalent to 
+Evaluation of a compound assignment of the form $v$ $\code{??=} e$ is equivalent to the evaluation of the expression  $((x) => x == \NULL?  v=e : x)(v)$ where $x$ is a variable that is not used in $e$. Evaluation of a compound assignment of the form $C.v$ $\code{??=} e$, where $C$ is a type literal, is equivalent to the evaluation of the expression  $((x) => x == \NULL?  C.v=e: x)(C.v)$ where $x$ is a variable that is not used in $e$. Evaluation of a compound assignment of the form $e_1.v$  $\code{??=} e_2$ is equivalent to the evaluation of the expression  $((x) =>((y) => y == \NULL?  x.v = e_2: y)(x.v))(e_1)$ where $x$ and $y$ are distinct variables that are not used in $e_2$. Evaluation of a compound assignment of the form  $e_1[e_2]$  $\code{??=} e_3$ is equivalent to the evaluation of the expression  

[Paul Berry, 2015/03/26 15:07:21]

Nit: the pdf output of this paragraph contains some confusing spaces.  For
example, "$v$ $\code{??=} e$" comes out looking like "v ?? =e" when the
intention is probably "v ??= e".  Similarly, "$((x) => x == \NULL?  v=e :
x)(v)$" comes out looking like "((x) => x == null?v = e : x)(v)", whereas when
coding one almost always puts spaces around the '?' operator.

[eernst, 2015/03/26 22:38:50]

If null-awareness should not change the number of times subexpressions are
evaluated then $e$ should be evaluated also if v == null.  A general pattern for
this could be to pass all subexpressions to the function expression rather than
just some of them.  Alternatively, the principle could be that as few as
possible of the given subexpressions should be evaluated for all null-aware
constructs, in which case nothing should be changed above.

[eernst, 2015/03/26 22:38:50]

Typo?: $((x) ..)(..)$ vs. \code{((x) $=>$ ..)(..)}.

[gbracha, 2015/03/26 23:21:22]

Yes, I am aware of that. I made some changes, but I still don't like how it
comes out. But I can fix typography later.  Today I should focus on semantics.

+$((a, i) => ((x) => x == \NULL?  a[i] = e_3: x)(a[i]))(e_1, e_2)$ where $x$, $a$ and $i$ are distinct variables that are not used in $e_3$. Evaluation of a compound assignment of the form $e_1?.v$  $\code{??=} e_2$ is equivalent to the evaluation of the expression \code{((x) $=>$ x == \NULL? \NULL: $x.v ??=  e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. 

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Need to address super.x ??= y too?

[eernst, 2015/03/26 22:38:50]

How about \code{$e_1$ == null}?

[gbracha, 2015/03/26 23:21:21]

Hmm. Actually, I think we don't really cover super.v = e or super[i] = e. 

[gbracha, 2015/03/26 23:21:22]

Done. 

[gbracha, 2015/03/26 23:21:22]

How about it :-) ? Sorry not clear what you mean. 

[eernst, 2015/03/27 08:44:03]

Actually, thinking about it, no special checking is needed in order to act
differently when \code{$e_1$ == \NULL}.  The anomaly is that we don't have

  e_1?[e_2] === ((a, i) => a == \NULL? \NULL : a[i])(e_1, e_2)

plus something similar to

  e_1?[e_2] = e_3 === ((a, i) => a == \NULL || i == \NULL? 
      \NULL : a[i] = e_3)(e_1, e_2)

And of course `e_1 ?@ e_2` for @ \in {+,-,*,/,...}.  ;)

+
+
+\LMHash{}
+The static type of a compound assignment of the form $v$ $\code{??=} e$ or the form $C.v$ $\code{??=} e$ is the static type of $e$. The static type of a compound assignment of the form $e_1.v$  $\code{??=} e_2$ is the static type of $e_2$. The static type of a compound assignment of the form $e_1[e_2]$  $\code{??=} e_3$ is the static type of $e_3$.

[Paul Berry, 2015/03/26 15:07:21]

I don't think this is what we want.  Consider the code:

f(num x) {
  (x ??= 1).modPow(2, 1000);
}

(Note that "modPow" is defined on the class "int" but not the class "num".)

As currently defined, this would produce no warnings, since the static type of
"x ??= 1" is the static type of "1", which is "int".  However, at runtime, if a
non-null value is passed to f(), then "x ??= 1" will evaluate to x, which is not
guaranteed to be an int.

I think we want to define the static type of "v ??= e" to be the least upper
bound of the static types of "v" and "e", similar to what we do for "v ?? e".

[gbracha, 2015/03/26 23:21:22]

Right. Likewise for all variants (v , C.v, e1.v, e1[e2]).

+
+\LMHash{}
+For any other valid operator $op$, a compound assignment of the form $v$ $op\code{=} e$ is equivalent to $v \code{=} v$ $op$ $e$. A compound assignment of the form $C.v$ $op \code{=} e$ is equivalent to $C.v \code{=} C.v$ $op$ $e$. A compound assignment of the form $e_1.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. A compound assignment of the form  $e_1[e_2]$ $op\code{=} e_3$ is equivalent to 
 \code{((a, i) $=>$ a[i] = a[i] $op$ $e_3$)($e_1, e_2$)} where $a$ and $i$ are a variables that are not used in $e_3$. 
+A compound assignment of the form $e_1?.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x?.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. 

[Paul Berry, 2015/03/26 15:07:21]

Nit: there are some spacing errors in this paragraph too.

 
-
 \begin{grammar}
 {\bf compoundAssignmentOperator:}`*=';
       `/=';
@@ -4248,7 +4500,8 @@
        `{\escapegrammar \gt \gt}=';
       `\&=';
       `\^{}=';
-      `$|$='
+      `$|$=';
+      `??=';
     .
 \end{grammar}
 
@@ -4261,7 +4514,7 @@
 
 \begin{grammar}
   {\bf conditionalExpression:}
-     logicalOrExpression (`?' expressionWithoutCascade `{\escapegrammar :}' expressionWithoutCascade)?
+     ifNullExpression (`?' expressionWithoutCascade `{\escapegrammar :}' expressionWithoutCascade)?
     . % the first  branches could  top level expressions, it seems, but certainly NOT the second
 \end{grammar}
 
@@ -4284,7 +4537,22 @@
 
 \LMHash{}
  It is a static type warning if the static type of $e_1$ may not be assigned to \code{bool}.  The static type of $c$ is the least upper bound (\ref{leastUpperBounds}) of the static type of $e_2$ and the static type of $e_3$.
+ 
+   
+ \subsection{If-null Expressions}
+ \label{ifNull}
+ 
+ \LMHash{}
+ An {\em if-null expression}evaluates an expression and if the result is \NULL, evaluates another.
+
+\begin{grammar}
+{\bf ifNullExpression:}
+  logicalOrExpression (`??' logicalOrExpression)*
+\end{grammar}
   
+\LMHash{}
+Evaluation of an if-null expression $e$ of the form $e_1??e_2 $ is equivalent to the evaluation of the expression $((x) => x == \NULL? e_2: x)(e_1)$. The static type of $e$ is least upper bound (\ref{leastUpperBounds}) of the static type of $e_1$ and the static type of $e_2$.
+  
 
 \subsection{ Logical Boolean Expressions}
 \LMLabel{logicalBooleanExpressions}
@@ -4633,7 +4901,7 @@
 
  \begin{grammar}
 {\bf postfixExpression:}assignableExpression postfixOperator;
-      primary selector*
+      primary (selector* $|$ ( `\#' ( (identifier `='?) $|$ operator)))

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Could the #-syntax be part of selector instead?

It's probably ok, and it does prevent the (arguably abusive) use:
  o#b()
Just want to be sure we are sure you never want to immediately do something to
an extracted function (like calling it or accessing a member of it).

[gbracha, 2015/03/26 23:21:21]

I'm not inclined to outlaw the abuse.

     .
 
 {\bf postfixOperator:}
@@ -4716,13 +4984,28 @@
     .
     
 {\bf assignableSelector:}`[' expression `]'; % again, could be top level
-      `{\escapegrammar .}' identifier
+      `{\escapegrammar .}' identifier;
+       `{\escapegrammar ?.}' identifier

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Different indentation?

[gbracha, 2015/03/26 23:21:22]

Acknowledged.

     .
 
 \end{grammar}
 
 \LMHash{}
-An {\em assignable expression} is either:
+An assignable expression can be {\em conditional} or {\em unconditional}.
+
+Evaluation of a {\em conditional assignable expression} $e$ of the form $e_1?.id$  is equivalent to the evaluation of the expression  $((x) => x == \NULL ? \NULL : x.id)(e_1)$. The static type of $e$ is the same as the static type of $e_1.id$.
+
+\commentary{
+One might be tempted to conclude that for $e \ne \NULL{}$, $e?.v$ is always equivalent to $e.v$. However this is not the case. If $e$ is a type literal representing a type with static member $v$, the $e.v$ refers to that member, but $e?.v$ does not.
+}
+
+\rationale{
+One could try and address this with special case rules, but this is simply a matter of digging oneself deeper into a hole. Removing the restrictions on the use of types as objects is the proper way to resolve this issue.

[Lasse Reichstein Nielsen, 2015/03/26 10:38:48]

Objection, editorializing!

[gbracha, 2015/03/26 23:21:22]

I am the editor, after all. I wondered if anyone would notice. 

+}
+
+
+\LMHash{}
+An {\em unconditional assignable expression} is either:
 \begin{itemize}
  \item An identifier. 
 \item An invocation of a getter (\ref{getters}) or list access operator on an expression $e$.
@@ -5667,7 +5950,7 @@
 A finally clause \FINALLY{} $s$ defines an exception handler $h$ that executes as follows:
 
 \LMHash{}
-Let $r$ be the current return value (\ref{return}). Then the current return value becomes undefined. Any open streams associated with any asynchronous for loops (\ref{asynchronousFor-in}) and yield-each (\ref{yieldEach}) statements executing within the dynamic scope of $h$ are canceled. 
+Let $r$ be the current return value (\ref{return}). Then the current return value becomes undefined. Any open streams associated with any asynchronous for loops (\ref{asynchronousFor-in}) and yield-each (\ref{yieldEach}) statements executing within the dynamic scope of $h$ are canceled, in the order of their nesting, innermost first. 
 
 \rationale{
 Streams left open by for loops that were escaped for whatever reason would be canceled at function termination, but it is best to cancel them as soon as possible.
@@ -5873,7 +6156,7 @@
 Let $s_b$ be a \BREAK{} statement. If $s_b$ is of the form  \code{\BREAK{} $L$;}, then let $s_E$ be the the innermost labeled statement with label $L$ enclosing $s_b$. If $s_b$ is of the form \code{\BREAK{};},  then let $s_E$ be the the innermost  \DO{} (\ref{do}), \FOR{} (\ref{for}), \SWITCH{} (\ref{switch}) or \WHILE{} (\ref{while}) statement enclosing  $s_b$. It is a compile-time error if no such statement $s_E$ exists within the innermost function in which  $s_b$ occurs.  Furthermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both enclosed in $s_E$ and that enclose  $s_b$, and that have a \FINALLY{} clause. Lastly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$.   Executing  $s_b$ first executes $f_1, \ldots,  f_n$ in innermost-clause-first  order and then terminates $s_E$. 
 
 \LMHash{}
-If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), its associated stream subscription is canceled. Furthermore, let $a_k$ be the set of asynchronous for loops  and yield-each statements (\ref{yieldEach}) enclosing $s_b$ that are enclosed in $s_E , 1 \le k \le m$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$. 
+If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), its associated stream subscription is canceled. Furthermore, let $a_k$ be the set of asynchronous for loops  and yield-each statements (\ref{yieldEach}) enclosing $s_b$ that are enclosed in $s_E , 1 \le k \le m$, where $a_k$ is enclosed in $a_{k+1}$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$, innermost first, so that $a_j$ is canceled before $a_{j+1}$. 
 
 
 
@@ -5897,7 +6180,7 @@
  }
  
 \LMHash{}
- If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), let $a_k$ be the set of asynchronous for loops and yield-each statements (\ref{yieldEach}) enclosing $s_c$ that are enclosed in $s_E , 1 \le k \le m$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$. 
+ If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), let $a_k$ be the set of asynchronous for loops and yield-each statements (\ref{yieldEach}) enclosing $s_c$ that are enclosed in $s_E , 1 \le k \le m$, where $a_k$ is enclosed in $a_{k+1}$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$, innermost first, so that $a_j$ is canceled before $a_{j+1}$. 
  
  \subsection{ Yield and Yield-Each}
  \LMLabel{yieldAndYieldEach}