Remove generalized tear-offs from the specification.

Remove generalized tear-offs from the specification.

Fixes issue #27519
BUG= http://dartbug.com/27519
R=eernst@google.com

Committed: https://github.com/dart-lang/sdk/commit/4cb61407a8bbd6050e876995f149b07cf9299445

[Lasse Reichstein Nielsen, 2016-11-03 11:38:58]

lrn@google.com changed reviewers:
+ eernst@google.com

[eernst, 2016-11-03 13:13:46]

LGTM.

I added a comment on the missing argument types in the closure created for a
given tear-off, but I decided that this should be a separate issue so we
shouldn't have do anything about that here (the issue is
https://github.com/dart-lang/dart-lang-evolution/issues/121).

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:4038: Unconditional property extraction has one
of two syntactic forms: $e.m$ (\ref{getterAccessAndMethodExtraction}) or
$\SUPER.m$ (\ref{superGetterAccessAndMethodClosurization}), where $e$ is an
expression and $m$ is an identifier.
I think we still need `optionally followed by an equals sign` at the end (I
can't immediately spot evidence for claiming that 'equal sign' is wrong, but I
think it means "a sign which is equal to something which was mentioned earlier
in this sentence" whereas 'equals sign' is definitely the '=').

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:4158: 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$.
Is it really true that closurization should drop the argument types?
'dart:mirrors' tells me that the vm preserves the original signature, which
would seem both natural and useful to me. Using function types which are not
assignable (that is, with an unrelated argument or return type rather than a
sub/super-type), I can see that the implementation matches the messages from the
reflection layer: A tear-off does get the type from the corresponding method, it
does not drop the argument types.

So I guess we should document that, because it's implemented and it's better, so
why would we adjust the implementations for the worse, just to keep this wording
unchanged?

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:4199: 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$.
Same issue as last time, with the missing argument types.

[Lasse Reichstein Nielsen, 2016-11-07 07:49:06]

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:4038: Unconditional property extraction has one
of two syntactic forms: $e.m$ (\ref{getterAccessAndMethodExtraction}) or
$\SUPER.m$ (\ref{superGetterAccessAndMethodClosurization}), where $e$ is an
expression and $m$ is an identifier.
I don't think we need the equals sign - that's the name of a setter and we can't
extract setters any more.

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:4158: 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$.
On 2016/11/03 13:13:46, eernst wrote:
> Is it really true that closurization should drop the argument types?

No.
We should fix it. The extracted function should have the same type as the
method. That's particularly important when you extract a call method.

[eernst, 2016-11-07 10:08:40]

lgtm

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2476613002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:4038: Unconditional property extraction has one
of two syntactic forms: $e.m$ (\ref{getterAccessAndMethodExtraction}) or
$\SUPER.m$ (\ref{superGetterAccessAndMethodClosurization}), where $e$ is an
expression and $m$ is an identifier.
On 2016/11/07 07:49:06, Lasse Reichstein Nielsen wrote:
> I don't think we need the equals sign - that's the name of a setter and we
can't
> extract setters any more.

Ah, of course. Acknowledged.

[Lasse Reichstein Nielsen, 2016-11-07 13:54:05]

Description was changed from

==========
Remove generalized tear-offs from the specification.

Fixes issue #27519
BUG= http://dartbug.com/27519
==========

to

==========
Remove generalized tear-offs from the specification.

Fixes issue #27519
BUG= http://dartbug.com/27519
R=eernst@google.com

Committed:
https://github.com/dart-lang/sdk/commit/4cb61407a8bbd6050e876995f149b07cf9299445
==========

[Lasse Reichstein Nielsen, 2016-11-07 13:54:06]

Committed patchset #1 (id:1) manually as
4cb61407a8bbd6050e876995f149b07cf9299445 (presubmit successful).