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

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ag0aep6g@gmail.com

--- Comment #1 from ag0aep6g@gmail.com ---
(In reply to Andrei Alexandrescu from comment #0)
> In this case the cure is simple - make Module a template parameterized on the module name/alias. But the matter gets a lot more problematic when trying to represent e.g. "all function declarations in this module".

If you have a better example, why not show it? How would you implement "all function declarations in this module" with/without the proposed feature?

Also, this needs to be a full-blown DIP, no? The restriction that all functions must be compilable for run time is in the spec and widely accepted (as far as I'm aware). If you want to lift it, you'll have to go into much more detail than you did here.

--

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

--- Comment #2 from Andrei Alexandrescu <andrei@erdani.com> ---
Happy to oblige!

struct Data
{
    string name;
    string type;
    string qualifier;
    string[] attributes;
}

Then the module can give you all top-level data declarations:

enum Data[] d = Module("mypack.mymod").data;
...

Indeed it is odd there'd be functions that only run during compilation. Need to think of that.

--

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

--- Comment #3 from ag0aep6g@gmail.com ---
(In reply to Andrei Alexandrescu from comment #2)
> Happy to oblige!
> 
> struct Data
> {
>     string name;
>     string type;
>     string qualifier;
>     string[] attributes;
> }
> 
> Then the module can give you all top-level data declarations:
> 
> enum Data[] d = Module("mypack.mymod").data;
> ...

Eh? Previously it was "function declarations", now it's "data declarations". And you've not given an implementation of either.

--

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

--- Comment #4 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to ag0aep6g from comment #3)
> (In reply to Andrei Alexandrescu from comment #2)
> > Happy to oblige!
> > 
> > struct Data
> > {
> >     string name;
> >     string type;
> >     string qualifier;
> >     string[] attributes;
> > }
> > 
> > Then the module can give you all top-level data declarations:
> > 
> > enum Data[] d = Module("mypack.mymod").data;
> > ...
> 
> Eh? Previously it was "function declarations", now it's "data declarations". And you've not given an implementation of either.

Somebody's in a testy mood :o). It was quicker to exemplify with data. Will follow up with a working sample.

--

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

--- Comment #5 from Andrei Alexandrescu <andrei@erdani.com> ---
Refer to https://github.com/andralex/introspect/blob/master/introspect.d. It defines Module as a template taking the module name as a string, and the data declarations work out nicely. I'll continue digging in that direction see where it goes.

--

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

Adam D. Ruppe <destructionator@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |destructionator@gmail.com

--- Comment #6 from Adam D. Ruppe <destructionator@gmail.com> ---
Why doesn't:

enum Data[] d = getModule!("mypack.mymod").data;


work? Where getModule is a small template that just returns the populated Module object with the CT data.

--

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

--- Comment #7 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to Adam D. Ruppe from comment #6)
> Why doesn't:
> 
> enum Data[] d = getModule!("mypack.mymod").data;
> 
> 
> work? Where getModule is a small template that just returns the populated Module object with the CT data.

Cool variant, thanks.

--

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

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #8 from hsteoh@quickfur.ath.cx ---
It's a bit ironic, but perhaps reading this might help explain why what you proposed doesn't work:

https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time

OTOH, why not just make the module name a template parameter? That would sidestep the issue:

----
struct Module(string name)
{
    string[] allMembers() {
        enum impl = __traits(allMembers, name);
        return impl;
    }
}
----

--

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

--- Comment #9 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to hsteoh from comment #8)
> It's a bit ironic, but perhaps reading this might help explain why what you proposed doesn't work:
> 
> https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
> 
> OTOH, why not just make the module name a template parameter? That would sidestep the issue:
> 
> ----
> struct Module(string name)
> {
>     string[] allMembers() {
>         enum impl = __traits(allMembers, name);
>         return impl;
>     }
> }
> ----

Whoa, great article. I didn't know about it. Thanks!

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--