On Friday, 29 August 2014 at 17:21:00 UTC, Philippe Sigaud via Digitalmars-d wrote:
> I remember using the same 'module' trick a few years ago (that is,
> getting a name with __traits and testing whether it begins with
> "module " or not) and, like Adam, being a bit ashamed by what I just
> did :) While reading his book this summe, I was, like, "Oh, then this
> is what we all do".
>
> Ideally, there should be a __traits(getModules) or
> __traits(getImports, ...). I know, I know, "where is the PR?".

I have this in my TODO list but I want to take care of other things in related domain first. DIP63 being the most important priority

On Friday, 29 August 2014 at 16:48:52 UTC, Andrei Alexandrescu wrote:
> Worth a look:
>
> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute
>
> Andrei

Cool stuff. Maybe it's just because I started programming D by doing compile-time reflection (and 3 of my dub packages use it), but I was mostly nodding along going "yeah, yeah, done stuff like that". :P

I like passing modules around as strings, that way I don't have to type the "import " part of it cos I'm super lazy. This means doing the same `mixin("import " ~ moduleName);` on the other side. I would've written:

    allWithSillyWalk!(onEach, "c", "mod.b")

instead of picking them up from the imports. Again, lazy. :P

Atila

On 8/29/14, 10:12 AM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Aug 29, 2014 at 09:48:51AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>> Worth a look:
>>
>> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute
> [...]
>
> Wow. That's ... awesome. Kudos to Adam for the ingenuity!!! Compile-time
> reflection FTW!
>
> The mixin("import "...) line was mind-blowingly ingenious, I have to
> say. As are the mixin(x) lines where x is an alias, to coax the compiler
> to recursively scan submodules. D seriously rawkz for compile-time
> reflection.

Worth redditing? Or too much information? :o)

Andrei

On Friday, 29 August 2014 at 19:04:33 UTC, Andrei Alexandrescu wrote:
>> The mixin("import "...) line was mind-blowingly ingenious, I have to
>> say. As are the mixin(x) lines where x is an alias, to coax the compiler
>> to recursively scan submodules. D seriously rawkz for compile-time
>> reflection.
>
> Worth redditing? Or too much information? :o)
>
> Andrei

Btw, while I remember it, doing mixin("static import ...") is highly recommended instead for namespace hygiene reason if you are actually going to do anything with found symbols.

On Friday, 29 August 2014 at 19:22:42 UTC, Dicebot wrote:
> Btw, while I remember it, doing mixin("static import ...") is highly recommended instead for namespace hygiene reason if you are actually going to do anything with found symbols.

Logical. I've never actually used this trick for anything serious though, indeed, the first time I attempted it was writing that answer. It just occurred to me that a mixin with local imports is a solution to getting deeper and I slapped it down.

Amusingly, this is now my highest rated SO answer ever.

On 2014-08-29 16:48:51 +0000, Andrei Alexandrescu said:

> Worth a look:
> 
> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute 
> 
> 
> Andrei

Is this bug fixed then?

https://issues.dlang.org/show_bug.cgi?id=11595

On Tuesday, 2 September 2014 at 22:30:59 UTC, Shammah Chancellor wrote:
> On 2014-08-29 16:48:51 +0000, Andrei Alexandrescu said:
>
>> Worth a look:
>> 
>> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute
>> 
>> 
>> Andrei
>
> Is this bug fixed then?
>
> https://issues.dlang.org/show_bug.cgi?id=11595

I have a PR open for this bug [0].
But I have had no feedback regarding it nor confirmation that it fixes the bug for others.
No idea if anybody else has done something for it as well.

[0] https://github.com/D-Programming-Language/dmd/pull/3921

On 2014-09-03 01:41:57 +0000, Rikki Cattermole said:

> On Tuesday, 2 September 2014 at 22:30:59 UTC, Shammah Chancellor wrote:
>> On 2014-08-29 16:48:51 +0000, Andrei Alexandrescu said:
>> 
>>> Worth a look:
>>> 
>>> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute 
>>> 
>>> 
>>> 
>>> Andrei
>> 
>> Is this bug fixed then?
>> 
>> https://issues.dlang.org/show_bug.cgi?id=11595
> 
> I have a PR open for this bug [0].
> But I have had no feedback regarding it nor confirmation that it fixes the bug for others.
> No idea if anybody else has done something for it as well.
> 
> [0] https://github.com/D-Programming-Language/dmd/pull/3921


Looks like you made this pretty recently.  Thanks!   That bug was quite a thorn in my side for awhile.

-Shammah

On 2014-08-29 16:48:51 +0000, Andrei Alexandrescu said:

> Worth a look:
> 
> http://stackoverflow.com/questions/25555329/d-finding-all-functions-with-certain-attribute 
> 
> 
> Andrei

That's some pretty neat code, I did something similar awhile ago for deserializing classes.  Here's a reduced case of it:

http://dpaste.dzfl.pl/4fffa339368f

The facility to be able to create such a factory through compile time reflection is absolutely awesome.  However, it "feels" as though the ability to do this is making use of undefined behavior rather than actual language features.

First:

I consider it sort of a language wart that alias hack(alias T) = T; is necessary for aliasing to the particular symbol, and that the __traits(getMember) expression can't be substituted in to the same places as the alias to it without compiler errors.   It's very non-intuitive.  I would have never figured that out on my own with out some other D wizards helping me about a year ago.  I still don't understand why I can't simply do :
		alias member = __traits(getMember, ...);

Also:

The way that the foreach works in the pasted example is very surprising.   I would be nice if this was a "static foreach" instead of just a foreach which happens to run at compile time over a TypeTuple.   Normally doing a switch inside a foreach like that would not work at all, but near as I can tell the compiler unrolls the whole thing since it's inputs are known at compile time.

Finally:

If you actually want to have something that returns a TypeTuple!() of only subclasses which you can foreach over in other places -- you have to make a *very* ugly recursive template:

	(Line 208 thru Line 235 returns a TypeTuple of all subclasses of the Message class)
	
	https://github.com/schancel/gameserver/blob/master/source/messages/core.d#L208

Making these awesome feature more intuitive and easy to use would go a long way.  I feel like this should be on your short list along with the GC and C++ compatibility.

-S.