Enable getSymbolsByUDA to retrieve private members.

[rcorre]

Resolves #15335: getSymbolsByUDA fails if type has private members.
Generous (ab)use of mixins allows getSymbolsByUDA to reference symbols
without trying to access them, allowing it to inspect private members
without failing.

Testing this required private symbols defined outside of std.traits.
This adds std.internal.test.uda, which defines a struct containing
private members that is used in a unittest added to std.traits.

My previous implementation, #3817, simply ignored private members.

[Hackerpilot]

This line is duplicated.

[rcorre]

@Hackerpilot: removed the duplicate test line, thanks!

[Hackerpilot]

Minor formatting complaint: remove the space between the " and the ..

[Hackerpilot]

Auto-merge toggled on

[MartinNowak]

Yikes, this does not work. Not all type names are correctly printable and you always use an alias instead of a mixin string to get them.
Could we somehow replace this with __traits(getMember, Type, name)?
Or maybe we have to change the API to return a bunch of strings like __traits(allMembers, Type) and leave it to the people to access the fields.

[rcorre]

Could we somehow replace this with __traits(getMember, Type, name)

Only if we change the API to only retrieve publically accessible members (even if those members are visible in the caller's module)

Or maybe we have to change the API to return a bunch of strings like __traits(allMembers, Type)

I don't think this matters as we'd still be using a mixin for hasSpecificUDA. Get rid of that mixin, and we can only support members visible to std.traits.

I'm not completely sure I understand the problem here, can you elaborate or give an example?

[rcorre]

Oh, there are deprecation warnings even with the code as-is. I think we'll have to give up on exposing members that std.traits can't access. Which could really limit the usefulness of this. Users will have to implement their own getSymbolsByUDA in every module they want to use it (if they want it to return non-public members with the UDA).

[MartinNowak]

Only if we change the API to only retrieve publically accessible members (even if those members are visible in the caller's module)

I think __traits(getMember) should bypass visibility checks, b/c it's a meta programming tool and similar use cases are needed in many places.

[MartinNowak]

Maybe I mixed that up with using formatted strings to rebuild the type, which doesn't work in many places.

auto test()
{
    struct S
    {
    }
    return S();
}

pragma(msg, typeof(test()).stringof);

But here you're just accessing the members of sth. which are always named.

[MartinNowak]

A mixin template might be viable alternative as well.

[schveiguy]

I think __traits(getMember) should bypass visibility checks, b/c it's a meta programming tool and similar use cases are needed in many places.

I'm not sure this is the best idea. __traits(getMember, x, "foo") is as easy to type as x.foo and can have disastrous consequences (if you mess with private data, you can screw up the expected invariants for a type).

I think the best mechanism is to allow access to private symbols if you have the alias already. That is, I can alias my private symbol, hand it off to some other module, and because it now has that key, it can unlock the data. This allows the module to retain control over private data.

[rcorre]

think the best mechanism is to allow access to private symbols if you have the alias already

I'd like this as well, but it won't be useful in this particular case. getSymbolsByUDA only gets the 'parent' symbol, so we still wouldn't be able to access private child symbols.

A mixin template might be viable alternative as well.

I think that would work, but it is a bit uglier on the calling end.