__traits so long and ugly, what about ::?

[Jonathan M Davis]

On 2011-03-30 19:38, KennyTM~ wrote:
> On Mar 31, 11 09:42, Ary Manzana wrote:
> > I just hate it when you have to write too much to get simple things
> > done.
> > 
> > Does this type have a member? Current approach:
> > 
> > 1. import std.traits;
> > 2. invoke hasMember!(S, "m")
> > 
> > Another approach:
> > 
> > 1. I have the type, let's ask it: S::hasMember("m")
> > 
> > Map's thought to code.
> > 
> > My problem is that when you start using D's cool features you end up
> > with a really hard to understand and obscure code...
> 
> How often do you really needs feature in __traits? I've grepped my code
> which uses a lot of templates and CTFE, and it only appears in 2 lines
> 
>      else static if (__traits(isScalar, T)) {
>          static if (__traits(compiles, T.init.re))
> 
> Therefore I oppose the use of :: just for __traits, because it's so rare.
> 
> Now I have a counter-proposal,
> 
>      T::ident(x, y, z, ...)  <=>  ident!(T, x, y, z, ...)
> 
> then hasMember can be invoked as
> 
>      import std.traits;
>      ...
>      S::hasMember("m")
> 
> Isn't it better than reserving :: just for __traits?

I use __traits(compiles, ) all the time, and a few of the others in __traits, 
though I probably use std.traits more than __traits.

I don't mind the meta proposal (__traits _is_ kind of ugly), but I 
_definitely_ don't like the :: proposal. I don't find it to be clear at all, 
and it's one more operator to remember. Not to mention, it might cause 
problems when porting C++ code.

- Jonathan M Davis