How do I defeat the gratuitous qualification of alias members?

Chad Joan chadjoan at gmail.com
Fri Apr 5 11:43:09 PDT 2013


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<chadjoan at gmail.com> 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.


More information about the Digitalmars-d-learn mailing list