On 04/05/2013 02:06 PM, Tobias Pankrath wrote:
On Friday, 5 April 2013 at 18:03:33 UTC, Chad Joan wrote:
On 04/05/2013 01:48 PM, Chad Joan wrote:
On 04/05/2013 01:18 PM, Andrej Mitrovic wrote:
On 4/5/13, Chad Joan<[email protected]> wrote:
Enums do not have instances.
Sure they do.
enum Foo
{
X,
Y
}
void test(Foo foo) { }
void main()
{
Foo foo = Foo.Y;
test(foo);
}
foo is the instance.
I can probably word this another way, since I might not have been
entirely clear.
Things like structs and classes occupy memory. Enums do not. Foo.Y
expands to an immediate value and has no storage in the program's data
segment. Enums place constraints on other things that do occupy
memory: usually integers.
foo does occupy memory. That foo is represented just like an integer
does not change this. foo could be a struct or an array, too.
At this point it is probably definitional.
I would prefer to define enums as a kind of constraint over types,
rather than as its own storable type. This is just much more useful to me.
Usage-wise, I see enums doing two things:
(1) Constraining function input/output to a named set of possible
values, at compile-time.
(2) Requiring constants to be qualified with a tag name.
I think that both of these are useful in different situations. What I
don't like is that they are tightly coupled.
Usually I want (1). (1) can eliminate sources of bugs. That's awesome.
Usually (2) is a hindrance to me. It causes a lot of line-wrapping and
noise. The D compiler is good enough at finding ambiguities and
erroring on them that I feel it is unnecessary in most situations (I'm
sure there are exceptions).
(2) is especially bad for flag sets that get ORed together. It's so
clumsy that it discourages the use of enums. Thus, having (2) tightly
coupled with (1) can undermine the benefits of (1). It runs against one
of Walter's design goals: the easy thing should be the safe and correct
thing. Right now the safe and correct thing requires extra noise and
line wraps; it is not easier.
I really just wish there was an easy way to pick-and-choose which
attributes are desired for a given enum, based on usage scenario.
I will probably be writing "mixin dequalifyEnum!SomeEnum;" next to a lot
of my enums from now on. It's just another papercut, like all of the
typedef'ing on structs in C.
