• WhatMeWorry (10/10) Jul 24 2015 Looking at the online documentation, it says:
• Jacob Carlborg (11/20) Jul 24 2015 A couple of reasons:
• Jonathan M Davis via Digitalmars-d-learn (21/31) Jul 24 2015 You can think of __traits as being the compiler and runtime support for ...

"WhatMeWorry" <kheaser gmail.com> writes:

Looking at the online documentation, it says:

__traits "are extensions to the language to enable programs, at 
compile time, to get at information internal to the compiler."

std.traits are "Templates which extract information about types 
and symbols at compile time.

Do they both basically do the same thing?  They both have 
isIntegral, but there is a lot of functionality that they don't 
share.

I guess one naive question would be, why not just have all the 
__traits functionality rolled into std.traits?  Or vice versa?

Jacob Carlborg <doob me.com> writes:

On 2015-07-24 09:16, WhatMeWorry wrote:
 Looking at the online documentation, it says:

 __traits "are extensions to the language to enable programs, at compile
 time, to get at information internal to the compiler."

 std.traits are "Templates which extract information about types and
 symbols at compile time.

 Do they both basically do the same thing?  They both have isIntegral,
 but there is a lot of functionality that they don't share.

 I guess one naive question would be, why not just have all the __traits
 functionality rolled into std.traits?  Or vice versa?

A couple of reasons:

* std.traits existed before __traits

* In some cases std.traits might provide a more user friendly interface 
than __traits. I think that __traits is not intended to be used directly 
by users. Rather it should server as a building block for a library 
implementation. That's why it has double underscore prefix.

* It's not possible to implement everything that __traits does in a 
library solution, i.e. std.traits

-- 
/Jacob Carlborg

Jonathan M Davis via Digitalmars-d-learn writes:

On Friday, July 24, 2015 07:16:41 WhatMeWorry via Digitalmars-d-learn wrote:
 Looking at the online documentation, it says:

 __traits "are extensions to the language to enable programs, at
 compile time, to get at information internal to the compiler."

 std.traits are "Templates which extract information about types
 and symbols at compile time.

 Do they both basically do the same thing?  They both have
 isIntegral, but there is a lot of functionality that they don't
 share.

 I guess one naive question would be, why not just have all the
 __traits functionality rolled into std.traits?  Or vice versa?

You can think of __traits as being the compiler and runtime support for type
introspection beyond what's found in is expressions, and std.traits as the
additions and wrappers that were put in the standard library to build on
what the compiler provides via is expressions and __traits.

__traits provides information that you can't get without the compiler's or
runtime's help. std.traits is all stuff that you could have theoretically
written yourself based on __traits or what's in the language (e.g.
std.traits.isIntegral is able to do what it does entirely with is
expressions and doesn't require __traits at all). What's in std.traits are
helper templates and are generally more user-friendly than __traits, even
if something in std.traits wraps something from __traits.

In theory, __traits was never really supposed to be used by users, but it's
never been completely wrapped by std.traits, so anyone doing heavy
metaprogramming is probably going to end up using both. __traits may or may
not ever be fully wrapped by std.traits, but it's not going away regardless,
so even if it were fully wrapped by std.traits later, your code which used
__traits would still be fine. It's just that at that point there would be
something in std.traits that you could use instead and which might be
a bit more user-friendly.

- Jonathan M Davis