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