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

bb.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bb.temp@gmx.com

--- Comment #1 from bb.temp@gmx.com ---
I've encountered a similar issue yesterday. It looks like the only way to solve this is to make `getSymbolsByUDA` a mixin template containing the current function. Then when the template is mixed in the local scope, there's no more fake warning in case when a private member is accessed (even in "friends" classes or struct, so inside the same module.

For example in my case I finished with this:

---
mixin template ScopedReachability()
{
    bool isMemberReachable(T, string member)()
    if (is(T==class) || is(T==struct))
    {
        return __traits(compiles, __traits(getMember, T, member));
    }
}
---

If I mix ScopedReachability where `isMemberReachable` has to be used it works. Previously, calling the function template was leading to the same error message that's reported here...



...So, back to real topic, by analogy:

---
mixin template ScopedgetSymbolsByUDA
{
    template getSymbolsByUDA(alias symbol, alias attribute)
    {
        import std.typetuple : Filter, staticMap, TypeTuple;

        static enum hasSpecificUDA(alias S) = hasUDA!(S, attribute);
        alias StringToSymbol(alias Name) = Identity!(__traits(getMember,
symbol,       Name));
        alias getSymbolsByUDA = Filter!(hasSpecificUDA, TypeTuple!(symbol,
        staticMap!(StringToSymbol, __traits(allMembers, symbol))));
    }

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

--- Comment #2 from ryan@rcorre.net ---
(In reply to bb.temp from comment #1)
> I've encountered a similar issue yesterday. It looks like the only way to solve this is to make `getSymbolsByUDA` a mixin template containing the current function.

Yeah, its messy. I'm not sure I'd want it to require users to mix in something, but I'm at a loss for how else we can return actual symbols.

It _can_ be implemented if you just want to return member names:

template getMembersByUDA(T, alias attribute)
{
    import std.meta : Filter;

    enum hasSpecificUDA(string name) = mixin("hasUDA!(T."~name~", attribute)");

    alias getMembersByUDA = Filter!(hasSpecificUDA, __traits(allMembers, T));
}

But then the user has to translate them to symbols using getMember on their end.

--

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

bb.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--- Comment #3 from bb.temp@gmx.com ---
I've looked at your PR on GH and obviously the first one is better since it just prevents the error.

The accessibility is a more global problem. Every time someone will put a function related to traits in a module and use this function in another module the same error will pop up. A mixin template allows to inject the function related to traits in the module it's used. So far it's ok, let's say for a private usage, (actually there's --0-- mixin template in phobos so I doubt they'll ever accept some new functions based on this, even if it works).

Maybe the real solution would be to make "__traits(getMember,...)", and more generally speaking all the traits verbs that might also block compilation because of this, able to return any member, regardless of the protection.

Then it would be up to the user to respect or not the protection using an additional "__traits(getProtection,...)" to filter an item in the traits code.

--

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

--- Comment #4 from ryan@rcorre.net ---
(In reply to bb.temp from comment #3)

> (actually there's --0-- mixin template in phobos so
> I doubt they'll ever accept some new functions based on this, even if it
> works).

Actually, Proxy is a mixin template. Still, it actually makes sense there, whereas using a mixin template for this feels a bit hackier.

> Maybe the real solution would be to make "__traits(getMember,...)", and more generally speaking all the traits verbs that might also block compilation because of this, able to return any member, regardless of the protection.

Yeah, it would be nice if getMember could distinguish between 'referring' to a member and 'accessing' a member. As a matter of fact, you _can_ do this, as my getMembersByUDA example shows. You can inspect SomeType.privateMember by building the expression out of a mixin; I just don't know if you can translate that to a symbol without violating privacy.

--

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

--- Comment #5 from ryan@rcorre.net ---
Here's another idea, this time with more mixins! Don't have time to test thoroughly right now but I _think_ its working with private members and giving back symbols rather than names:

template getMembersByUDA(T, alias attribute) {
  import std.string : format;
  import std.meta : Filter;

  template toSymbols(names...) {
    static if (names.length == 1)
      mixin("alias toSymbols = AliasSeq!(T.%s);".format(names[0]));
    else
      mixin("alias toSymbols = AliasSeq!(toSymbols!(names[1..$]),
%s);".format(names[0]));
  }

  enum hasSpecificUDA(string name) = mixin("hasUDA!(T."~name~", attribute)");

  alias membersWithAttribute = Filter!(hasSpecificUDA, __traits(allMembers,
T));

  alias getMembersByUDA = toSymbols!(membersWithAttribute);
}

mixins are like violence ... if they don't work you're not using enough of
them.
I'll test more later and put up a separate PR if it looks more promising.

--

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

Johan Engelen <jbc.engelen@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jbc.engelen@gmail.com

--- Comment #6 from Johan Engelen <jbc.engelen@gmail.com> ---
Should this have been closed?
See:
https://github.com/dlang/phobos/commit/79fd6aac7956179b300c43f3320347ce0c1fe46b
No PR for that commit?

--

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

--- Comment #7 from Johan Engelen <jbc.engelen@gmail.com> ---
PR is https://github.com/dlang/phobos/pull/3827

--

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

Mitu <the.mail.of.mi2@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |the.mail.of.mi2@gmail.com

--- Comment #8 from Mitu <the.mail.of.mi2@gmail.com> ---
The bug still persists.

--

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

Mitu <the.mail.of.mi2@gmail.com> changed:

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

--- Comment #9 from Mitu <the.mail.of.mi2@gmail.com> ---
*** Issue 17643 has been marked as a duplicate of this issue. ***

--

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

Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |simen.kjaras@gmail.com
         Resolution|---                         |FIXED

--- Comment #10 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
Fixed in 2.079 by https://github.com/dlang/phobos/pull/6085

--