Enum literals, good? bad? what do you think?
claptrap
clap at trap.com
Tue Jul 20 20:43:15 UTC 2021
On Tuesday, 20 July 2021 at 16:12:05 UTC, H. S. Teoh wrote:
> On Tue, Jul 20, 2021 at 03:50:49PM +0000, russhy via
> Digitalmars-d wrote:
>> Hello
>>
>> I all the time wondered why we always have to be so much
>> verbose with enum, when it's not casting to primitives, it is
>> about repeating their long type name, constantly, all the time
> [...]
>
> OT1H, having to qualify enums by their full name is good, it
> helps to avoid the mess in C where libraries sometimes define
> conflicting values under the same name, e.g.,
>
> // somelib.h
> #define ERROR 0
> #define OK 1
>
> // someotherlib.h
> #define ERROR -1
> #define OK 0
>
> In D, if you used an enum, you'd have to quality which ERROR or
> OK you're referring to, which avoids conflicts and also avoids
That's irrelevant i think, since #defines are like anonymous
enums, and you dont need to save typing on those. With named
enums in D i think you'd know (most or all? of the time) which
one it is by the context... Eg..
enum SomeResult { OK, Error }
enum OtherResult { Error, OK }
You cant assign or pass SomeResult.OK to something that is
expecting an OtherResult can you?
So if you have a function...
void handleError(OtherResult r);
and call it thus...
handleError(OK);
You know it's OtherResult.OK
Isnt that the point of strong typing?
More information about the Digitalmars-d
mailing list