__traits so long and ugly, what about ::?

[Don]

Alix Pexton wrote:
> On 31/03/2011 18:37, Jonathan M Davis wrote:
>> On 2011-03-31 06:35, Kagamin wrote:
>>> Ary Manzana Wrote:
>>>> I just hate it when you have to write too much
>>>
>>> hasMember!(S, "m")
>>> is only 1 character longer than
>>> S::hasMember("m")
>>>
>>> not too much for me
>>
>> And hasMember!(S, "m") is actually consistent with the rest of the 
>> language
>> and straight forward to read for those who know the language.
>> S::hasMember("m") just adds more syntax where there's no need for it, and
>> makes it so that there's that much more syntax to learn and keep 
>> straight.
>>
>> - Jonathan M Davis
> 
> I thought the :: syntax seemed pretty intuitive (keystroke savings never 
> entered into my evaluation), but I seem to be in a minority on that.
> 
> After re-reading the previous discussion of __traits and its proposed 
> replacement, however, I am reminded of an important point: language 
> features should not have special powers that can't be replicated in 
> client code.
> 
> So, with that in mind, I have to agree that using templates for things 
> like hasMember has to be the way forward.
> 
> Having templates that are internal to the complier or that simply 
> forward to __traits seems a bit odd to me. I think I'd rather see 
> __traits simplified and more of work moved into the library, which may 
> make it more versatile and easier to extend (pure speculation ^^).
> 
> Right, I'm off to go and squirrel all my uses or traits away inside 
> templates, I have a sneaking suspicion that it is going to make some big 
> improvements in readability ^^
> 
> A...
The chief problem is that there is no way to hide __traits(compiles).
It's just impossible. The whole idea of the meta namespace was to make 
it possible to hide the __traits.

Don't forget that an important part of that proposal was to clean up 
is(), as well.