Implementing a Programming Language in D: Lexical Analysis
burjui via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Wed Dec 30 06:41:38 PST 2015
On Tuesday, 29 December 2015 at 05:57:34 UTC, Ali Çehreli wrote:
> I've realized that with a nested anonymous enum, there is no
> need to (and no way of) mentioning the enum type inside a
> user-defined type. This can simplify the implementation:
Only if you intend to use enum members as manifest constants,
otherwise you're losing the type safety and explicitness
offered by named enums.
For example, I wouldn't use an anonymous enum for lexeme types.
> enum {
> a,
> ulong b = 42, c, // b and c are ulong
> s = "hello", // an inferred string between integrals!
> x = 7, y, z
> }
For me, it's a clear example of unnecessary over-engineering.
> However, move 's' to the end of the list or remove it
> altogether,
> then x, y, and z become ulong! Weird.
It's even worse than that: x, y and z will still be int (inferred
from 7).
This code
> void main()
> {
> enum {
> a,
> ulong b = 42, c, // b and c are ulong
> x = 7, y, z
> }
> import std.stdio, std.typecons;
> tuple!(typeof(b), typeof(c), typeof(x)).writeln;
> }
will print
> Tuple!(ulong, ulong, int)(0, 0, 0)
which is somewhat counter-intuitive. I would suggest to remove
this feature
as useless and bug-prone. The following is much clearer IMHO,
even though it's more verbose:
> enum { a }
> enum: ulong { b = 42, c }
> enum { s = "hello" }
> enum { x = 7, y, z }
Even more than that, I would also suggest to remove anonymous
auto-typed enums
without an initial value from which type can be inferred, e.g.:
> enum { a } // a is an int implicitly
Again, the following is not much harder to write, but the type of
'a' is immediately clear:
> enum: int { a } // a = int.init, obviously
Although I understand that these are breaking changes,
and D is too mature to break anything (almost not being
sarcastic).
More information about the Digitalmars-d-announce
mailing list