Transferred the generalized void informal spec to docs/language/informal

Transferred the generalized void informal spec to docs/language/informal

R=lrn@google.com

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

[eernst, 2017-08-09 13:19:14]

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

[eernst, 2017-08-09 13:19:15]

This CL moves the current informal spec of the generalized void feature into
docs/language/informal (it allows void in most locations where types are
allowed, in syntax and semantically, and mandates constraints on the usage of
values of type void).

The most controversial points that we had on this topic are the following:
  - do we allow developers to force usage of a value of type void: `e as T`
(where `e` has type void and T is some other type than void)? 
  - do we allow type tests, `e is T`, `e is! T`?

We also discussed for a long time whether we should specify that `void` and
`Object` are distinct types or they are the same type (but where representations
of that type is allowed to "remember" whether it was written as `void` or
written as `Object`, such that we can get nice error messages). I believe that
this topic matters less for the rest of the world (seemingly, we can decide on
one or the other, and the substance of the mechanisms will be the same).

We have some tests in https://codereview.chromium.org/2707933002/, and I've
commented on them. They assume that `b ? e1 : e2` allows for `e1` and `e2` to be
void; I believe that we decided (after those tests were written) that developers
must use the longer form using `if`, and hence we don't allow `?:` with void
values. If we decide otherwise then I need to add that to the spec. Otherwise we
should adjust the tests to stop expecting that it can be used.

[Lasse Reichstein Nielsen, 2017-08-09 13:41:42]

lgtm

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
File docs/language/informal/generalized-void.md (right):

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:15: type `void` as a type annotation,
and as a type argument.
Not sure there should be a comma here.

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:25: avoid using such a value.
Is it worth mentioning that the type parameter of `Future` is really
representing a return type, which is why the lack of `Future<void>` hurts so
much when converting from synchronous code to asynchronous?

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:42: second phase may be added to Dart
1.x later, or it may only be provided in
Definitely not going into Dart 1.0, everything we do from now on is Dart 2.

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:64: We plan to introduce a **voidness
preservation analysis** (which is similar
plan -> intend

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:68: it is never added to Dart 1.x. In
any case, voidness preservation is a
Again, we are past Dart 1.x now.

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:79: specification as of June 2nd,
2017 (git commit 0603b18).
We will need to update this for Function types (which are also not usable as
classes, so typeNotVoid would be typeNotVoidOrFunction).
Is that worth mentioning now?

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:264: It is a static warning for an
expression to have type void, except for the
In Dart 2, this will be a compile-time error, so just switch to that now.

[eernst, 2017-08-09 14:30:04]

Review response.

Remaining issue: I have conflicting input on whether the "wrong usages" (such as
`var x = myVoidExpression;`) should be static warnings or compile-time errors.
I'd prefer errors, but have no strong opinion. At this point I've left it
unchanged (as a warning).

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
File docs/language/informal/generalized-void.md (right):

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:15: type `void` as a type annotation,
and as a type argument.
On 2017/08/09 13:41:42, Lasse Reichstein Nielsen wrote:
> Not sure there should be a comma here.

Done.

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:25: avoid using such a value.
On 2017/08/09 13:41:42, Lasse Reichstein Nielsen wrote:
> Is it worth mentioning that the type parameter of `Future` is really
> representing a return type, which is why the lack of `Future<void>` hurts so
> much when converting from synchronous code to asynchronous?

Added a small paragraph mentioning this, and using `Future` as an example.
Interestingly, `Future` _never_ uses `T` contravariantly (of course the value
must be passed to the Future in some concrete `FutureImpl` class, but `Future`
itself doesn't reveal that).

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:42: second phase may be added to Dart
1.x later, or it may only be provided in
On 2017/08/09 13:41:42, Lasse Reichstein Nielsen wrote:
> Definitely not going into Dart 1.0, everything we do from now on is Dart 2.

Removed the entire sentence. Everything will be about Dart 2 very soon anyway.

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:64: We plan to introduce a **voidness
preservation analysis** (which is similar
On 2017/08/09 13:41:42, Lasse Reichstein Nielsen wrote:
> plan -> intend

Done.

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:68: it is never added to Dart 1.x. In
any case, voidness preservation is a
On 2017/08/09 13:41:42, Lasse Reichstein Nielsen wrote:
> Again, we are past Dart 1.x now.

Deleted the part that mentions language versions: '.. this document**. Voidness
preservation is a purely static..'.

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:79: specification as of June 2nd,
2017 (git commit 0603b18).
On 2017/08/09 13:41:42, Lasse Reichstein Nielsen wrote:
> We will need to update this for Function types (which are also not usable as
> classes, so typeNotVoid would be typeNotVoidOrFunction).
> Is that worth mentioning now?

The reference to the spec grammar below (CL 2688903004) shows the interactions
among these two extensions, because it contains both.

https://codereview.chromium.org/2994003002/diff/1/docs/language/informal/gene...
docs/language/informal/generalized-void.md:264: It is a static warning for an
expression to have type void, except for the
On 2017/08/09 13:41:42, Lasse Reichstein Nielsen wrote:
> In Dart 2, this will be a compile-time error, so just switch to that now.

Ah, that's funny: I had 'compile-time error' here until June 13th because we
might as well make it an error now (given that it would become an error in Dart
2 anyway), but then I was asked to change it to static warning, in order to make
it fit in Dart 1.x.

So right now I just have two requests (yours and Florian's), and I don't have
any strong opinions on the issue myself, so I'll keep it unchanged and then we
can go and fix it as needed. ;)

[eernst, 2017-08-09 14:31:03]

Description was changed from

==========
Transferred the generalized void informal spec to docs/language/informal
==========

to

==========
Transferred the generalized void informal spec to docs/language/informal

R=lrn@google.com

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

[eernst, 2017-08-09 14:31:04]

Committed patchset #2 (id:20001) manually as
db092ff2fcc8f3f2107c864a8bd170d4d7d1f519 (presubmit successful).