Annoyances with traits

[F i L]

I find myself using __traits(hasMember, T, "member") a lot.
It's really basic feature of meta-programming.

I'm not a fan of the "__usedByCompiler" syntax, but that's a
whole different discussion. __traits() is fine (besides the fact
that first-argument-as-function is syntactically inconsistent to
the rest of the language), but std.traits doesn't wrap it
correctly; and, because it's globally available anyways & so
often used, shouldn't have to be imported to use in the first
place, IMO.

What I would like to see happen: Have a traits.d which replaces
std.traits and is always included (like object.d) which properly
wraps __trait functions.

so in traits.d:

      // use alias T, so we can pass "laser.x" to it
      // without having to pass typeof(laser.x). Just like
      // we can with using __traits(hasMember, ...)

      template hasMember(alias T, string member) {
          enum hasMember = __traits(hasMember, T, member);
      }

we can then write:

      auto laser = ship.fire();
      static if(traits.hasMember!(laser.x, "isProp") ...;

which feels syntactically consistent. Because traits are in their
own module, we could emit the "traits." and just call
"hasMember()". Even better, if UFCS allows, we could simply write:

      static if(laser.x.hasMember!("isProp")) ...;


my 2 cents.