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.

On 28 March 2012 07:29, F i L <witte2008@gmail.com> wrote:

> 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.
>

I was rummaging through exactly the same stuff yesterday, and reached a
similar conclusion.
My code became borderline impossible to understand very fast with all the
references to __traits(getMember, instanceOf, member) and friends.
Something like you suggest would go a long way to making it readable again.

One thing I noticed recurring, __traits(getMember, T, member) can be aliased, but __traits(getMember, instanceOfT, member) can not really be aliased, since D doesn't have references. Is there a practical way to do this? Granted, it's not so necessary if the syntax to do that wasn't so long and cumbersome.

The other thing I found was within a few functions I was desperately wanting user attributes. I was interacting with a database, and without being able to attribute row structure items, it's very messy and hacky to specify which item was the primary key, which items should be relational references, mask items which should be ignored, etc.

Am Wed, 28 Mar 2012 06:29:30 +0200
schrieb "F i L" <witte2008@gmail.com>:

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

We already had this discussion 3 years ago, there's even a bug report:

http://d.puremagic.com/issues/show_bug.cgi?id=3702 http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_Replace_traits_and_is_typeof_XXX_with_a_magic_namespace_._99914.html

And related: http://forum.dlang.org/thread/in00fa$4fa$1@digitalmars.com?page=1

I think someone just has to implement that 'meta' namespace and start a pull request, I doubt there will be a big resistance against it.

My proposal:
http://www.digitalmars.com/d/archives/digitalmars/D/Yet_another_compile-time_reflection_revisited_proposal_150309.html

On 28 March 2012 20:01, RivenTheMage <riven-mage@id.ru> wrote:

> My proposal:
> http://www.digitalmars.com/d/**archives/digitalmars/D/Yet_**
> another_compile-time_**reflection_revisited_proposal_**150309.html<http://www.digitalmars.com/d/archives/digitalmars/D/Yet_another_compile-time_reflection_revisited_proposal_150309.html>


Yes please! :)
Although I'm not sure why you distinguish 'metainfo' from 'meta'?

These proposals all look basically the same, more or less.
I'm curious to know why it wasn't done that way in the first place? It
seems the obvious approach...

On Wednesday, 28 March 2012 at 17:01:50 UTC, RivenTheMage wrote:
> My proposal:
> http://www.digitalmars.com/d/archives/digitalmars/D/Yet_another_compile-time_reflection_revisited_proposal_150309.html

I like this idea more than the one I purposed.

On Wednesday, 28 March 2012 at 22:23:51 UTC, Manu wrote:

> Although I'm not sure why you distinguish 'metainfo' from 'meta'?

To me, it's consistent with .typeinfo and .classinfo properties.

I'd like to add to what I suggested earlier. Conversion between
types is a common and expected behavior. Because std.conv is
small, and the new UFCS is here, I think object.d could benefit.
Hear what I had in mind:

+ Move std.conv functionality to object.d
+ Move Object.toString() from the base class, to free space.
+ Make toString() simply wrap to!string() and depreciate it.
+ Replace parse!() with a more intelligent to!()/string

+ emplace!() would be handy to always have around :)
+ idk what to do with text!() :/

Now we can convert types as a language feature, and toString()
still works, but universally on any type that defines opCall().
Also, like I said, toString() might just wrap to!string() and be
marked as depreciated (since we already have .stringof).

     auto name = "Jacque Fresco";
     auto age = 96;

     writeln("Hi, I'm ", name, ".");
     writeln("I'm ", age.text(), " years old");
     writeln("This shit's got to go!"); // ;)

     writeln("How old are you?");

     auto line = readln();
     auto theirAge = line.to!int();

On 29 March 2012 20:07, F i L <witte2008@gmail.com> wrote:

>     auto name = "Jacque Fresco";
>     auto age = 96;
>
>     writeln("Hi, I'm ", name, ".");
>     writeln("I'm ", age.text(), " years old");
>     writeln("This shit's got to go!"); // ;)
>

Hah!
Nicely played ;)

On Thursday, 29 March 2012 at 21:29:04 UTC, Manu wrote:
> On 29 March 2012 20:07, F i L <witte2008@gmail.com> wrote:
>
>>     auto name = "Jacque Fresco";
>>     auto age = 96;
>>
>>     writeln("Hi, I'm ", name, ".");
>>     writeln("I'm ", age.text(), " years old");
>>     writeln("This shit's got to go!"); // ;)
>>
>
> Hah!
> Nicely played ;)

XD

I was hoping someone would get that reference.