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

           Summary: __traits should have isFunction, isVariable, etc
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: jmdavisProg@gmail.com


--- Comment #0 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-07-04 18:59:56 PDT ---
At present, __traits has some nice stuff that will let you check things like whether a function is abstract, or whether something is of an integral type. It will even let you get all of the member functions and variables of a class. However, there is no way at present (as far as I can tell) to determine whether something is a function or a variable. There isn't a way to determine if something is a type either, let alone whether it's a class, struct, array, or scalar type. Most of what's there seems to be to ask about the attributes of a particular expression, variable, or type rather than telling you what it _is_. In particular, I think that we need these __traits:

isArray
isClass
isFunction
isStruct
isType
isVariable

-- 
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=4427


Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simen.kjaras@gmail.com


--- Comment #1 from Simen Kjaeraas <simen.kjaras@gmail.com> 2010-07-05 07:52:08 PDT ---
> isArray

std.traits has isArray

> isClass

This is easily done with is( T == class ).

> isFunction

This is easily done with is( T == function ).

> isStruct

This is easily done with is( T == struct ).

> isType

is( T )?

> isVariable

(!is( T ) && is( typeof( T )))?

-- 
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=4427



--- Comment #2 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-07-05 18:12:14 PDT ---
Good points, though would == function check when it was a function pointer rather than a function? In either case, I think that you should be able to check these in a consistent manner, which you can't do right now. With things spread out between built-in constructs, __traits, and std.traits, it can be a bit of a mess to figure out how to do something with compile-time reflection. Even if something like isType were simply translated to is(T), I think that having it would still be quite valuable since it would make the various compile-time reflection facilities more consistent and uniform.

-- 
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=4427



--- Comment #3 from Simen Kjaeraas <simen.kjaras@gmail.com> 2010-07-06 04:29:56 PDT ---
I agree. Many of these could easily be turned into templates in std.traits, and perhaps they should.


template isClass( T ) {
    enum isClass = is( T == class );
}

unittest {
    interface I {}
    class A {}
    class B( T ) {}
    class C : B!int, I {}
    struct S {}

    static assert( isClass!A );
    static assert( isClass!( B!int ) );
    static assert( isClass!C );
    static assert( !isClass!I );
    static assert( !isClass!S );
    static assert( !isClass!int );
    static assert( !isClass!( int* ) );
}

template isInterface( T ) {
    enum isInterface = is( T == interface );
}

unittest {
    interface I {}
    class A {}
    class B( T ) {}
    class C : B!int, I {}
    struct S {}

    static assert( !isInterface!A );
    static assert( !isInterface!( B!int ) );
    static assert( !isInterface!C );
    static assert( isInterface!I );
    static assert( !isInterface!S );
    static assert( !isInterface!int );
    static assert( !isInterface!( int* ) );
}

template isStruct( T ) {
    enum isStruct = is( T == struct );
}

unittest {
    interface I {}
    class A {}
    class B( T ) {}
    class C : B!int, I {}
    struct S {}

    static assert( !isStruct!A );
    static assert( !isStruct!( B!int ) );
    static assert( !isStruct!C );
    static assert( !isStruct!I );
    static assert( isStruct!S );
    static assert( !isStruct!int );
    static assert( !isStruct!( int* ) );
}

template isType( T ) {
    enum isType = true;
}

template isType( alias T ) {
    enum isType = false;
}

unittest {
    struct S {
        alias int foo;
    }

    static assert( isType!int );
    static assert( isType!float );
    static assert( isType!string );
    //static assert( isType!S ); // Bugzilla 4431
    static assert( isType!( S.foo ) );
    static assert( !isType!4 );
    static assert( !isType!"Hello world!" );
}

I'm not entirely sure what you want isVariable to do. Does it check if something can be assigned to (i.e. is variable), or are immutable and const 'variables' also variables?

-- 
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=4427



--- Comment #4 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-07-06 10:05:58 PDT ---
I would expect that immutable and const variables would still be variables, just not mutable ones. If you wanted to know whether they were const or immutable, you could do a separate test for that on top of checking whether something was a variable, just like you'd do if you wanted to know whether it were static.

Personally, I've been trying to figure out how to get the list of non-static member variables out of a class at compile-time, and it's been a bit of a pain. And for what I'm doing with them, I wouldn't care whether they were immutable or const.

-- 
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=4427


Jacob Carlborg <doob@me.com> changed:

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


--- Comment #5 from Jacob Carlborg <doob@me.com> 2010-07-07 04:02:46 PDT ---
(In reply to comment #4)
> I would expect that immutable and const variables would still be variables, just not mutable ones. If you wanted to know whether they were const or immutable, you could do a separate test for that on top of checking whether something was a variable, just like you'd do if you wanted to know whether it were static.
> 
> Personally, I've been trying to figure out how to get the list of non-static member variables out of a class at compile-time, and it's been a bit of a pain. And for what I'm doing with them, I wouldn't care whether they were immutable or const.

You can use object.tupleof to get a list of member variables of out a class at compile time. You can also have a look at http://www.dsource.org/projects/orange/browser/orange/util/Reflection.d (look for the templates/functions containing "field") to get some ideas to implement helper templates/functions.

-- 
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=4427


Rob T <alanb@ucora.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alanb@ucora.com


--- Comment #6 from Rob T <alanb@ucora.com> 2012-11-16 14:07:14 PST ---
(In reply to comment #2)
> Good points, though would == function check when it was a function pointer rather than a function? In either case, I think that you should be able to check these in a consistent manner, which you can't do right now. With things spread out between built-in constructs, __traits, and std.traits, it can be a bit of a mess to figure out how to do something with compile-time reflection. Even if something like isType were simply translated to is(T), I think that having it would still be quite valuable since it would make the various compile-time reflection facilities more consistent and uniform.

I wasted an hour on this very issue because it's not obvious in the least how to do something like isStruct() for a template constraint.

I don't mind using is( T == struct ), so long how to do such a thing (and other tests) is documented in an obvious place that someone is going to look at, like in the templates constraint section. That section currently has nothing in it of much help other than showing how to constrain a few basic types.

-- 
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=4427



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-11-16 15:46:47 PST ---
I had forgotten that I created this enhancement request, though I don't know how valid it is at this point given how powerful is expressions are (though how to fully use them isn't well enough known).

> I wasted an hour on this very issue because it's not obvious in the least how to do something like isStruct() for a template constraint.

> I don't mind using is( T == struct ), so long how to do such a thing (and other tests) is documented in an obvious place that someone is going to look at, like in the templates constraint section. That section currently has nothing in it of much help other than showing how to constrain a few basic types.

It's explained in the section on is expressions:

http://dlang.org/expression.html#IsExpression

However, that documentation is fairly sparse, and given the extreme flexibility and power (and therefore complication) of is expressions, we could really use a solid tutorial on them on the site. Phillippe Segaud has an extension tutorial on templates in general on github though:

https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf

-- 
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=4427



--- Comment #8 from Rob T <alanb@ucora.com> 2012-11-17 08:31:39 PST ---
(In reply to comment #7)
> I had forgotten that I created this enhancement request, though I don't know how valid it is at this point given how powerful is expressions are (though how to fully use them isn't well enough known).
> 
> > I wasted an hour on this very issue because it's not obvious in the least how to do something like isStruct() for a template constraint.
> 
> > I don't mind using is( T == struct ), so long how to do such a thing (and other tests) is documented in an obvious place that someone is going to look at, like in the templates constraint section. That section currently has nothing in it of much help other than showing how to constrain a few basic types.
> 
> It's explained in the section on is expressions:
> 
> http://dlang.org/expression.html#IsExpression
> 
> However, that documentation is fairly sparse, and given the extreme flexibility and power (and therefore complication) of is expressions, we could really use a solid tutorial on them on the site. Phillippe Segaud has an extension tutorial on templates in general on github though:
> 
> https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf

Thanks for the response! I have no idea how I skipped the section on Expressions, probably because at the time I was too new with D to understand what it was good for. lot's to read up on in there. Looks like it covers everything I can imagine is needed.

Yes it seems that with availability of expressions the enhancement request is somewhat redundant, and like you said, making people aware of it may be what's needed most.

-- 
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=4427


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> 2012-11-17 13:40:36 PST ---
> Many of these could easily be turned into templates

The is ==struct and __traits are not really intended to be user-facing. They are intended to be embedded into templates which then can present a simple, straightforward user interface.

Sometimes those templates do need to work hard internally to get the information, but being able to is all that's relevant.

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