On 2016-08-31 02:04, Ali Çehreli wrote:

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

I agree. Let private stop you from access symbols though the regular ways, but let reflection bypass.

-- 
/Jacob Carlborg

On 2016-08-31 08:20, Jacob Carlborg wrote:

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

I think this was introduced already in 2.071.0.

-- 
/Jacob Carlborg

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

In addition to using .tupleof to bypass protection it's possible to return a pointer to the symbol to bypass protection as well, fixing that would require some serious flow analysis. It's also possible to inspect the symbol table to access private symbols at runtime.

-- 
/Jacob Carlborg

On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
>
> 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.

"lots of optimizations"
Can you mention a few?

(I can only think of complicated stuff that requires pretty much whole-program analysis to prove validity, and in that case adding `private` doesn't help any more)

-Johan

On Wed, 31 Aug 2016 08:22:31 +0200, Jacob Carlborg wrote:

> On 2016-08-31 02:04, Ali Çehreli wrote:
> 
>> 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.
> 
> I agree. Let private stop you from access symbols though the regular ways, but let reflection bypass.

Just like the JVM and .NET. And Python's double underscore name mangling, which is more to highlight that you're doing something funky. And Dart's mirrors. And `instance_variable_get` in Ruby.

On 2016-08-31 15:51, Chris Wright wrote:

> And `instance_variable_get` in Ruby.

Or "send", "instance_eval" and so on. In Ruby it's more of a comment, "please do call this method directly" :)

-- 
/Jacob Carlborg

On 08/31/2016 02:08 AM, 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.
> 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.

I think such change is not appropriate in a point release, not matter if it is going to happen or not.

On 8/31/16 5:56 AM, Johan Engelen wrote:
> On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
>>
>> 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.
>
> "lots of optimizations"
> Can you mention a few?

I'm not sure optimizations are had by private variables. Some optimizations can be had because the compiler can prove a variable could not have been changed. But I don't know that private suits that need, it's more due to const or immutable.

> (I can only think of complicated stuff that requires pretty much
> whole-program analysis to prove validity, and in that case adding
> `private` doesn't help any more)

Where I see private helping is conceptual -- I know that if a variable is private, I can narrow to a given module all the places the variable might be read or written. If you just allow private access via anywhere, it defeats that analysis.

-Steve

On Thursday, 1 September 2016 at 20:46:50 UTC, Steven Schveighoffer wrote:
> On 8/31/16 5:56 AM, Johan Engelen wrote:
>> On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
>>>
>>> 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.
>>
>> "lots of optimizations"
>> Can you mention a few?
>
> I'm not sure optimizations are had by private variables. Some optimizations can be had because the compiler can prove a variable could not have been changed. But I don't know that private suits that need, it's more due to const or immutable.

Yep.
I was trying to be polite :-)

On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
> 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.

i really HATE modern trend of turning tables. am i the only one who thinks that the machine was designed to serve the human, not vice versa? yet somehow we all trying to make our machines happy now, instead of using 'em.

the most funny thing with it is that modern software is bloated, dog slow, resource hungry and barely usable. so all this "please the machine" movement is completely pointless!