[Issue 9065] Please consider adding these std.traits

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #17 from Manu <turkeyman at gmail.com> 2012-11-26 10:18:05 PST ---
(In reply to comment #16)
> (In reply to comment #14)
> 
> > Perhaps this will help:
> > 
> > foreach(m; __traits(allMembers, something))
> > {
> >   // What on earth is m?
> >   // I think think you can argue this is unconventional code.
> >   // I need to know all sorts of things about m in this context, and I have
> > absolutely no prior information.
> >   // 'is' traits shouldn't make me jump through bunches of hoops to gather
> > information.
> > }
> 
> I agree with you in general but what's wrong with that example? Sure, the
> double underscore prefix doesn't look that nice but except from that. What
> would the alternative be? Something like this:
> 
> foreach (m; allMembers!(somethnig))
> {
>     // What on earth is m?
> }
> 
> What's better with that code? The "allMembers" trait is clearly documented
> here: 
> 
> http://dlang.org/traits.html#allMembers
> 
> "m" would be a string, since __traits(allMembers, something) returns a tuple of
> strings.

*sigh*

Sorry, I take no issue with allMembers. My point has nothing to do with
allMembers except that it's a common source of symbols that you have no idea
what they are.

** "what on earth is mixin(m)?"

If you don't know what something is you need to query details about it, and
with all the traits as britle and scarce as they are, chances are that leads to
many compile errors and consequently rubbish code scattered to protect it
against such errors, when rather, such 'is' traits should just produce 'false'
instead of compile errors.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------