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?

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

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