Beta D 2.071.2-b3

[Ali Çehreli via Digitalmars-d-announce]

On 08/30/2016 04:54 PM, Martin Nowak wrote:
 > On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote:
 >> On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
 >>> I'm a bit sad to see that
 >>> https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored
 >>> to fix issue 15907. Another decision could have been to break the
 >>> visibility for the traits allMember, getMember, derivedMember and
 >>> getOverloads.
 >>
 >> Well there was reasoning to choose that solution instead of the other
 >> (https://github.com/dlang/dmd/pull/6078) and the fact that private
 >> members aren't accessible (set/get) is a good indication that nobody
 >> needs this.
 >
 > As in needs private members in __traits(allMembers).
 >
 >> Adding an unsafe facility to access private members is a separate
 >> problem, but please see the changelog for how to achieve this already
 >> by mixing in templates.
 >
 > Allowing access to private members has a lot of implications, e.g.
 > breaks lots of optimizations b/c you can't know who accesses sth. It's
 > also yet unclear what effect this has on @safe and we'd not only have to
 > modify visibility but remove the access checks as well. This is clearly
 > too much to just fix that problem w/ certain template instantiations,
 > none of which should work on private members atm.
 > Also you'd have to change a lot of existing code, or it would now just
 > operate on private members.

How is this supposed to work? What is the new guideline and who should 
bear the new guideline; the library author or the user?

For this to work, the users must know that the library will call 
__traits(allMembers) so that they mixin and otherwise don't? That would 
be wrong in the other direction, no? The client needing to know about 
the library code? Wrong principle...

What if I add a new private member to my otherwise public struct? Then I 
should remember to mixin all N templates that my module happens to be 
using right now?

The only correct action that I see is that every template must be 
mixed-in in case I have a private member in the future or the library 
implementation may change in the future.

I'm sorry but this is not usable.

Ali

P.S. While I'm on my soapbox, I've started to think private is overrated 
anyway. A system language should allow to bypass that protection. 
private should be a recommendation only.