is(x = module) vs. __traits(isModule, x)

[Steven Schveighoffer]

On 10/8/20 3:15 PM, Paul Backus wrote:
> On Thursday, 8 October 2020 at 17:55:21 UTC, Steven Schveighoffer wrote:
>>
>> I did getMember already.
> 
> You did getMember for a type, not a variable. getMember for a type 
> evaluates to a symbol, but getMember for a variable evaluates to an 
> expression.

I wrote:

alias foomember = someTInstance.getMember("foo");

with the assumption that someTInstance was an instance of T. I didn't 
specify it was a runtime variable, but I did intend for that to be the case.

It's not possible to use a template to get an alias to a runtime member, 
so it would have to be something different that is allowed in 
typefunctions. But I assume the "alias" type that is inside a 
typefunction can be able to handle this, as you can *pass in* an alias 
to a runtime member, you just can't *return* an alias to a runtime 
member (well, you can, but it doesn't retain it's runtime component).

> 
>> I'm not sure that's 100% true for type functions -- they aren't in 
>> there yet.
> 
> In order to do everything that __traits can do, type functions would 
> have to be polymorphic, which is contrary to their design goals.

__traits are a way to introspect what already exist. At least the 
*traits* part of __traits (not __traits(compiles)). This doesn't mean 
it's polymorphic necessarily.

I can see for instance, __traits(getMember, x, "foo") returning an alias 
to the foo member inside a type function. It can't fetch a *usable 
value* from that alias. So for example, if x.foo is an integer, you 
can't get at the integer. But you can get at an alias to that member to 
do further introspection (i.e. check if it has a certain UDA, etc.)

In the land of reification for example, you could have a "getMember" 
method that uses pre-built information to fetch an alias to the member 
you are concerned about, which could carry along the type information 
about that member, and it's offset, and whatever else you need to then 
`dereify` the result.

__traits are like a window into the compiler's already-existing type 
information system. I can't see why we couldn't allow access to those 
things for type functions.

-Steve