Language specification: Support generalized void

[eernstg]

This is the language specification specific issue for #30176, which has the details.

Edit, Mar 19, 2018: At this point the feature specifications have been landed, so the language design decisions are in place; the missing part is updating dartLangSpec.tex accordingly.

[eernstg]

A feature spec about generalized void has been landed and is available here. The language specification has not yet been extended to include anything on the topic.

[eernstg]

Added milestone for reaching the level where the updated feature spec has been landed (resolving CLs 35680, 35920, 38060, 35740).

[eernstg]

For the generalized void feature, we currently have the following CLs (check mark means that it has been landed):

• Make nonvoid-to-void return an error (makes void f() { return 42; }, void f() async* .., and void f() sync* .. an error). Landed as 9f9987f.
• Make for-in on a void iterator an error, except when the iteration variable is void. Landed as c01d59b.
• Allow void expressions as ?: branches (a simple change): Abandoned as of Feb 20 2018.
• Allow void-to-void data flow: The language team committed to this approach as of Feb 20 2018; landed as 7d07f8d on Mar 14 2018.

[eernstg]

For the record, some discussions on the topics of the CLs mentioned in the previous comment took place in issue #30177 on generalized void in the analyzer.

[dgrove]

Is there an update on status of this?

[eernstg]

Done, finally. ;)

[eernstg]

Actually, what's done is the actual language design (the conceptual foundation, the formal rules), but it's all in feature specs, dartLangSpec.tex has not been updated yet. So I'm reopening this, having edited the initial comment on this issue to indicate what's missing.

[eernstg]

Done in 5b3b199.