Enums.

Enums.

R=kasperl@google.com

Committed: https://code.google.com/p/dart/source/detail?r=39385

[gbracha, 2014-08-18 20:38:55]

If only all spec changes were this simple.

[Bob Nystrom, 2014-08-18 21:36:45]

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

https://codereview.chromium.org/483873002/diff/1/docs/language/dartLangSpec.t...
docs/language/dartLangSpec.tex:1890: The declaration of an enum of the form
\code{metadata \ENUM{} E  = \{ id$_1$, \ldots id$_n$\};}
I don't pretend to read Tex, but is this line inconsistent with 1886? Should
there be an "=" between the enum type name and "{" or not?

[kasperl, 2014-08-19 05:04:35]

I think the privacy of the _name field is the biggest issue left. How can avoid
it being accessible from the defining library? Maybe we just shouldn't use the
_-based privacy and just give 'name' an identifier that cannot be written in
user code?

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1890: The declaration of an enum of the form
\code{metadata \ENUM{} E \{ id$_1$, \ldots id$_n$\};}
You could consider calling these id$_0$ to id$_{n-1}$ to avoid confusion with
the index.

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1900: \STATIC{} \CONST{} E id$_n$ = const E(n -
1, `id$_{n-1}$');
`id$_{n-1}$' should be `id$_n$'.

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1909: It is compile-time error to access the
private fields of an enumerated type anywhere outside its definition.
How can we tell statically?

Is there any way we can specify it so that enums are conceptually in their own
library so the library privacy mechanism works for us?

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1917: % should this be rephrased so that these
rules go elsewhere (i.e., in the rules for new/const/extends/implements/with?)
Haven't you already done so?

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:2822: It is a compile-time error if the type $T$
in an instance creation expression of one of  the forms
one of  the forms -> one of the forms (I know it will not be visible in the PDF
version, but anyway).

[gbracha, 2014-08-19 17:54:41]

PTAL

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1890: The declaration of an enum of the form
\code{metadata \ENUM{} E \{ id$_1$, \ldots id$_n$\};}
On 2014/08/19 05:04:35, kasperl wrote:
> You could consider calling these id$_0$ to id$_{n-1}$ to avoid confusion with
> the index.

Done.

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1900: \STATIC{} \CONST{} E id$_n$ = const E(n -
1, `id$_{n-1}$');
On 2014/08/19 05:04:35, kasperl wrote:
> `id$_{n-1}$' should be `id$_n$'.

Not anymore.

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1909: It is compile-time error to access the
private fields of an enumerated type anywhere outside its definition.
On 2014/08/19 05:04:35, kasperl wrote:
> How can we tell statically?
> 
> Is there any way we can specify it so that enums are conceptually in their own
> library so the library privacy mechanism works for us? 

The problem is that the surrounding library would have to have an import. Note
that nothing says you have to actually implement things using a _name field.
since the field is hidden everywhere including reflection. So  strictly
speaking, the spec is fine. It might be clearer to implementors if we did give
some suitable scheme in the spec - but it is all overspecification.

Anyway, the map idea works better, and eliminates the need for a special rule
etc. Much nicer.

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1917: % should this be rephrased so that these
rules go elsewhere (i.e., in the rules for new/const/extends/implements/with?)
On 2014/08/19 05:04:35, kasperl wrote:
> Haven't you already done so?

Yes, I have. This is just an old comment. I'll get rid of it.

https://codereview.chromium.org/483873002/diff/20001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:2822: It is a compile-time error if the type $T$
in an instance creation expression of one of  the forms
On 2014/08/19 05:04:35, kasperl wrote:
> one of  the forms -> one of the forms (I know it will not be visible in the
PDF
> version, but anyway).

Done.

[kasperl, 2014-08-19 18:09:01]

https://codereview.chromium.org/483873002/diff/40001/docs/language/dartLangSp...
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/483873002/diff/40001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1900: \STATIC{} \CONST{} E id$_1$ = \CONST{} E(0,
`id$_0$');
id$_1$ -> id$_0$ (etc...)

[gbracha, 2014-08-19 18:21:55]

https://codereview.chromium.org/483873002/diff/40001/docs/language/dartLangSp...
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/483873002/diff/40001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1900: \STATIC{} \CONST{} E id$_1$ = \CONST{} E(0,
`id$_0$');
On 2014/08/19 18:09:01, kasperl wrote:
> id$_1$ -> id$_0$ (etc...)

Argh. Fixed.

[kasperl, 2014-08-19 18:24:03]

Getting closer!

https://codereview.chromium.org/483873002/diff/60001/docs/language/dartLangSp...
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/483873002/diff/60001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1898: \FINAL{} String \_name;
Remove _name from here, the constructor, and all constructor calls.

[gbracha, 2014-08-19 18:27:29]

https://codereview.chromium.org/483873002/diff/60001/docs/language/dartLangSp...
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/483873002/diff/60001/docs/language/dartLangSp...
docs/language/dartLangSpec.tex:1898: \FINAL{} String \_name;
On 2014/08/19 18:24:02, kasperl wrote:
> Remove _name from here, the constructor, and all constructor calls.

Done.

[kasperl, 2014-08-19 18:39:49]

LGTM.

[gbracha, 2014-08-19 21:39:49]

Committed patchset #6 manually as r39385 (presubmit successful).