www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4427] New: __traits should have isFunction, isVariable, etc

reply d-bugmail puremagic.com writes:
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: -------
Jul 04 2010
next sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 05 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 05 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 06 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 06 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 07 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4427


Manu <turkeyman gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |turkeyman gmail.com


--- Comment #10 from Manu <turkeyman gmail.com> 2012-11-24 14:49:05 PST ---
(In reply to comment #9)
 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.
Well with this in mind, perhaps we can complete the suite of std.traits? There are a lot missing. I'd certainly like to clean up that aspect of my code before I depart, as it's the most confusing and unreadable section by far. Particularly for new-comers who haven't taken the time to wrangle those sorts of problems yet (who I will be leaving it to) :/ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 24 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4427


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com


--- Comment #11 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-01-09
14:30:51 PST ---
I've lost track here, what's left to implement that requires the compiler's
help by exposing a new __trait?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 09 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4427



--- Comment #12 from Manu <turkeyman gmail.com> 2013-01-12 03:18:49 PST ---
(In reply to comment #11)
 I've lost track here, what's left to implement that requires the compiler's
 help by exposing a new __trait?
I think the __trait's were more or less good now (at least for me personally), and Kenji had a bug/task where he was fleshing out std.traits. I'm not sure where that landed. I copied his example/prototype code locally and used that, not sure if it was ever completed/merged/documented. Sorry, I've been a major advocate for this stuff, and I'm currently AWOL. Back in 2-3 more weeks and I'll start making noise again ;) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4427



--- Comment #13 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-01-12
11:54:22 PST ---
Jonathan can you give us an updated on what's still missing?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 12 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4427



--- Comment #14 from Rob T <alanb ucora.com> 2013-03-29 00:06:50 PDT ---
(In reply to comment #13)

I would like to see something like isNullable(T) that evaluates to true if the
type value can be assigned a null.

Eg,

struct S { ... }
S* s; 
class C { ... }

isNullable( S ) is false
isNullable( typeof(s) ) is true
isNullable( C ) is true

--rt

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