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



--- Comment #10 from David Nadlinger <code@klickverbot.at> 2012-11-25 01:19:38 PST ---
(In reply to comment #9)
> std.traits operates on types, so I would not expect isSomeFunction!bar to ever work. You need to pass it a type. That's how everything in that module works.

This is definitely not true. Just have a look at isSomeFunction/isCallable resp. their unit tests.

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

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



--- Comment #11 from Manu <turkeyman@gmail.com> 2012-11-26 06:14:46 PST ---
Okay, I've worked my templates a little more, consider these:

// test if something is a type
template isType( alias T )
{
    enum isType = is( T );
}
template isType( T )
{
    enum isType = is( T );
}

// test if something is a function
// wrap this up, 'function' is an overloaded term, confusing for newbies
template isFunction( alias T )
{
    enum isFunction = is( typeof( T ) == function );
}
template isFunction( T )
{
    enum isFunction = is( T == function );
}

// test if something is an enum (used by isVariable)
template isEnum( alias T )
{
    template knownAtCompileTime( alias T )
    {
//        enum knownAtCompileTime = is( typeof( { enum e = T; } ) ); //
immutable breaks this check
        enum knownAtCompileTime = !__traits(compiles, ( ref typeof( T ) x ) {}(
T ) ); // hack to see if we can pass it by ref
    }

    enum isEnum = is( typeof( T ) == enum ) || knownAtCompileTime!T;
}
template isEnum( T )
{
    enum isEnum = is( T == enum );
}

// test if something is a variable; has a value, has an address
template isVariable( alias T )
{
    enum isVariable = !is( T ) && is( typeof( T ) )    // if it is not a type,
and does have a type, it starts to look like a variable
        && !isFunction!T                            // reject function
definitions, they can't be assigned to
        && !isEnum!T                                // reject enum's
        && !is( typeof( T ) == void );                // reject modules, which
appear as a variable of type 'void'
}
template isVariable( T )
{
    enum isVariable = false; // types aren't variables
}


This seems to be working for me now (caught a few more edge cases that would
fail on occasion). I'd really like to see all of these in std.traits.
It would be ideal if is() was a rare occurrence, it produces bracket spam, and
most I work with barely understand it past expressions like: is(T == int)

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

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



--- Comment #12 from Kenji Hara <k.hara.pg@gmail.com> 2012-11-26 06:47:09 PST ---
(In reply to comment #11)
> Okay, I've worked my templates a little more, consider these:
[snip]

1. I would never agree with isFunction. They introduce huge confusion but has no benefit. Blending traits about type and symbol is not a purpose of std.traits.

2. isEnum should be separated to isEnumType and isManifestConstant (with better name). Blending traits is very poor design.

And, there is no use case. if you propose an enhancement, you should show one or more use cases in order to claim its usefulness.

(I always doubt the reason like "for the newbie". Increase of language newbies is not worth than an increase of the design confusion in the standard library.)

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

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



--- Comment #13 from Manu <turkeyman@gmail.com> 2012-11-26 07:45:34 PST ---
Turns out this is still incomplete:

isEnum fails in some situations. Using 'compiles' like that is not reliable
with various levels of aliases/templates.
Also, that implementation of isVariable marks getter-properties as if they are
variables, which they are not.

Back to the drawing board...

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

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



--- Comment #14 from Manu <turkeyman@gmail.com> 2012-11-26 08:13:04 PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > Okay, I've worked my templates a little more, consider these:
> [snip]
> 
> 1. I would never agree with isFunction. They introduce huge confusion but has no benefit. Blending traits about type and symbol is not a purpose of std.traits.

You would never agree with a std.traits to wrap is(x == function)? Why? It confuses everyone. Nobody expects that overload of meaning.

> 2. isEnum should be separated to isEnumType and isManifestConstant (with better name). Blending traits is very poor design.

I've never heard this term 'manifest constant' before today.

Here's a line of code:
  enum i = 10;

I (and I presume any sane person) would say "that's an enum!".
I appreciate there is a distinction between an enum type and an enum value, but
they are both called enums, and I doubt any non-D-compiler-developer would
presume otherwise.

I don't care if they are separated, just that the terminology should make sense.

> And, there is no use case. if you propose an enhancement, you should show one or more use cases in order to claim its usefulness.

I work in a studio on highly sensitive proprietary code. Isolating examples out of context is often difficult, annoying, and very time consuming. I don't have the time to convince you in this case. However, if there wasn't a use case, rest assured I wouldn't be posting here, and I wouldn't be wasting consecutive days of my time on it. I need to know these things, D doesn't provide this information; it should.

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 always doubt the reason like "for the newbie". Increase of language newbies is not worth than an increase of the design confusion in the standard library.)

Confusion? Surely you mean simplification?

Having 'function' mean 2 to different things in 2 contexts is confusing. Having enum mean 2 different things in almost precisely the same context is confusing.

std.traits is meant to simplify my code and save me time. In my experience to date, it's severely lacking.

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

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



--- Comment #15 from Manu <turkeyman@gmail.com> 2012-11-26 08:24:02 PST ---
(In reply to comment #13)
> Turns out this is still incomplete:
> 
> isEnum fails in some situations. Using 'compiles' like that is not reliable
> with various levels of aliases/templates.
> Also, that implementation of isVariable marks getter-properties as if they are
> variables, which they are not.
> 
> Back to the drawing board...

I've become convinced I also need to add
template isProperty(T) { ... }

I can't find any sensible way to do this, and I'm also blocked without it.

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

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


Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com


--- Comment #16 from Jacob Carlborg <doob@me.com> 2012-11-26 09:59:57 PST ---
(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.

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

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



--- Comment #17 from Manu <turkeyman@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: -------

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



--- Comment #18 from David Nadlinger <code@klickverbot.at> 2012-11-26 11:11:13 PST ---
(In reply to comment #14)
> Here's a line of code:
>   enum i = 10;
> 
> I (and I presume any sane person) would say "that's an enum!".
> I appreciate there is a distinction between an enum type and an enum value, but
> they are both called enums, and I doubt any non-D-compiler-developer would
> presume otherwise.
> 
> I don't care if they are separated, just that the terminology should make sense.

Yes, but the correct answer to this is to not overload the word "enum" with two different meanings. Unfortunately, this ship has long sailed, but this still doesn't mean that we should repeat this mistake in the standard library, further adding confusion. If you don't like the term manifest constant, maybe isEnumConstant/isEnumType?

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

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



--- Comment #19 from Manu <turkeyman@gmail.com> 2012-11-26 11:47:52 PST ---
(In reply to comment #18)
> (In reply to comment #14)
> > Here's a line of code:
> >   enum i = 10;
> > 
> > I (and I presume any sane person) would say "that's an enum!".
> > I appreciate there is a distinction between an enum type and an enum value, but
> > they are both called enums, and I doubt any non-D-compiler-developer would
> > presume otherwise.
> > 
> > I don't care if they are separated, just that the terminology should make sense.
> 
> Yes, but the correct answer to this is to not overload the word "enum" with two different meanings. Unfortunately, this ship has long sailed, but this still doesn't mean that we should repeat this mistake in the standard library, further adding confusion. If you don't like the term manifest constant, maybe isEnumConstant/isEnumType?

Sure, just as long as something useful is added to std.traits.

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