Beta D 2.071.2-b3

Third beta for the 2.071.2 release. This beta fixes spurious deprecation warnings with templates using getMember (Issue 15907), please read the changelog for more details. http://dlang.org/changelog/2.071.2.html http://dlang.org/download.html#dmd_beta Please report any bugs at https://issues.dlang.org -Martin

On Tuesday, 30 August 2016 at 19:37:25 UTC, Martin Nowak wrote: > Third beta for the 2.071.2 release. > > This beta fixes spurious deprecation warnings with templates using getMember (Issue 15907), please read the changelog for more details. > > http://dlang.org/changelog/2.071.2.html > http://dlang.org/download.html#dmd_beta > > Please report any bugs at https://issues.dlang.org > > -Martin 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.

On 08/30/2016 02:58 PM, Basile B. wrote: > On Tuesday, 30 August 2016 at 19:37:25 UTC, Martin Nowak wrote: >> Third beta for the 2.071.2 release. >> >> This beta fixes spurious deprecation warnings with templates using >> getMember (Issue 15907), please read the changelog for more details. >> >> http://dlang.org/changelog/2.071.2.html >> http://dlang.org/download.html#dmd_beta >> >> Please report any bugs at https://issues.dlang.org >> >> -Martin > > 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. > +1 I've just opened a discussion thread on the main newsgroup about the (un)usability of this fix before seeing your comment. Ali

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. 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.

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.

August 30, 2016

Re: Beta D 2.071.2-b3

Posted by Ali Çehreli
in reply to Martin Nowak

Permalink

Ali Çehreli

Posted in reply to Martin Nowak

Permalink

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.

On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote: > As in needs private members in __traits(allMembers). and in the end it just producing excessive noise in common loops that does `is(typeof(__traits(getMember, ...)))`. it would be better to either leave that alone and allow all access, or exclude inaccessible members gin `allMembers` completely. yet D choose the third way, combining the worst features from both solutions.

On Wednesday, 31 August 2016 at 05:23:34 UTC, ketmar wrote: > On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote: >> As in needs private members in __traits(allMembers). > > and in the end it just producing excessive noise in common loops that does `is(typeof(__traits(getMember, ...)))`. it would be better to either leave that alone and allow all access, or exclude inaccessible members gin `allMembers` completely. yet D choose the third way, combining the worst features from both solutions. oops. seems that i did something wrong with myself. i'm sorry, the PR you linked seems to do exactly what i described. dunno how i managed to completely misunderstand it.

On 2016-08-31 01:08, Martin Nowak wrote: > 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. Class/struct fields are accessible using .tupleof. I was using __traits(getAttributes) in my serialization library to get UDA's for these fields, including private ones. -- /Jacob Carlborg

Forums