UDAs on enum members

[EntangledQuanta via Digitalmars-d]

On Sunday, 17 July 2016 at 20:51:42 UTC, Walter Bright wrote:
> On 7/13/2016 4:57 AM, Tomer Filiba wrote:
>> It would be really nice if I could put UDAs on enum members as 
>> well, e.g.,
>>
>> enum MyEnum {
>>     @("SOM") SomeMember,
>>     @("ANO") AnotherMemberWithAVeryLongName,
>> }
>
> Not a bad idea. It's been asked for before.
>
>
>> And while we're on the subject, why can't enums have methods? 
>> At the risk of
>> sounding as if I like Java (I don't :) ), it's a really nice 
>> language feature.
>> Back to our example:
>>
>> enum MyEnum {
>>     @("SOM") SomeMember,
>>     @("ANO") AnotherMemberWithAVeryLongName;
>>
>>     string dump() {
>>         ...  // `this` is a value, not a ref here
>>     }
>>     static MyEnum load(string name) {
>>         ...
>>     }
>> }
>>
>> Basically just allow a semicolon at the end of the members, 
>> after which methods
>> could appear. Adding members or whatever else Java has is an 
>> overkill -- just
>> use a struct for that. But instead of lots of dumpMyEnum(MyEnum
>> e)/loadMyEnum(string s) pairs, you could write 
>> myMember.dump()/MyEnum.load(s)
>
>
> struct MyEnum {
>     @("SOM") enum SomeMember = 0;
>     @("ANO") enum AnotherMemberWithAVeryLongName = 1;
>
>     string dump() {
>         ...  // `this` is a value, not a ref here
>     }
>     static MyEnum load(string name) {
>         ...
>     }
> }
>
> Not as nice, but gets the job done. But adding a new aggregate 
> type comes with a lot of baggage. I'm not convinced the 
> complexity is worth the benefit, which seems minor.

If it's a simple rewrite rule then there is no complexity. I 
don't see how adding UDA's to enums is a new aggregate type(it's 
still an enum).

The problem with such rewrites by the user is that the structs do 
not behave as enums and so all the mechanisms that enums have 
won't work. This creates problems, bugs, kludges, etc.

Maybe the problem is that the implementation of UDA's is not 
expressive enough to modify in a simple way? So fixing the code 
to make it do what it should have done in the first place is 
where the complexity lies?

Having UDA's are as useful as having them. How do you know how 
useful they can be until it is done? I have several perfectly 
valid use cases for them, and the hacks are 10x much work and may 
break some code that depends them actually being enum's.

You should realize that what you see as minor is not necessarily 
minor and what you think is not beneficial is only your relative 
opinion about yourself. What would be more helpful is for you to 
state what criteria you would need to actually put in the effort 
to implement the new features rather than stating opinions that 
only shut down progress.

Just remember there are at least 10's of thousands of D users and 
your experiences with writing D code is only one small aspect. 
Many D users that come from different backgrounds will have 
different understandings and different approaches to how they 
will write *their* code and what they expect. While you owe them 
nothing, it would be nice to at least acknowledge their view as 
relevant. If something is a theoretical contradiction, that is 
one thing, and it must be proved so... but is something is simply 
not done out of priority, laziness, convenience, etc then that is 
another.

If dmd is properly written then the complexity of adding new 
features should be compartmentalized and relatively localized. 
While one can never predict the ramifications of adding new 
features(both good and bad), I think this is why there are 
experimental versions of dmd? New features should not be looked 
upon with disdain but be welcomed. The potential issues and 
complexity that seem to be brought up can be mitigated with the 
proper approaches.