On Wednesday, 31 August 2016 at 09:56:17 UTC, Johan Engelen wrote:
> (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)

Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing loads/stores and indirect calls.

On Wednesday, 31 August 2016 at 06:20:46 UTC, 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.

Which is a weird implementation, b/c there is no direct alignment between allMembers and .tupleof.
Why not just use `__traits(getAttributes, var.tupleof[0])`?
Just serializing private state of types seems flawed too.

On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote:
> Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing loads/stores and indirect calls.

This doesn't really work that easily due to templates that depend on private data, and private data being referenced from alias parameters.

Of course, all such cases can still be statically detected when compiling the module in question, but this is quite a bit less trivial than just looking at the protection level.

 — David

On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote:
> On Wednesday, 31 August 2016 at 09:56:17 UTC, Johan Engelen wrote:
>> (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)
>
> Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing loads/stores and indirect calls.

There are enough ways to leak access to private entity (alias, template argument, taking address, some compile-time introspection) to make such optimizations impossible without extensive program analysis.

On 2016-09-03 18:02, Martin Nowak wrote:

> Why not just use `__traits(getAttributes, var.tupleof[0])`?

I've already updated my code to use the above. When I first implemented it, it was not possible to use a "tupleof expression" as argument to __traits(getAttributes).

-- 
/Jacob Carlborg

On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
> On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote:
>> On Wednesday, 31 August 2016 at 09:56:17 UTC, Johan Engelen wrote:
>>> (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)
>>
>> Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing loads/stores and indirect calls.

This is a very naive viewpoint.

> There are enough ways to leak access to private entity (alias, template argument, taking address, some compile-time introspection) to make such optimizations impossible without extensive program analysis.

Exactly.

On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
> There are enough ways to leak access to private entity (alias, template argument, taking address, some compile-time introspection) to make such optimizations impossible without extensive program analysis.

OK, anything else that would be impaired by allowing access to private members?
I think the unsafe requirement Walter asked for would be too much for the point release.
We could create an intermediate solution that ignores visibility but still keep the access checks around (basically the old behavior) until most of them will get removed in a later release.

On Sunday, 4 September 2016 at 08:57:15 UTC, Martin Nowak wrote:
> On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
>> There are enough ways to leak access to private entity (alias, template argument, taking address, some compile-time introspection) to make such optimizations impossible without extensive program analysis.
>
> OK

Agreed that such optimizations would require quite some front-end additions (keeping track if anything aliases or escapes the symbol), so it might not be worth with the current state of LTO.

On Sunday, 4 September 2016 at 08:57:15 UTC, Martin Nowak wrote:
> On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
>> There are enough ways to leak access to private entity (alias, template argument, taking address, some compile-time introspection) to make such optimizations impossible without extensive program analysis.
>
> OK, anything else that would be impaired by allowing access to private members?
> I think the unsafe requirement Walter asked for would be too much for the point release.
> We could create an intermediate solution that ignores visibility but still keep the access checks around (basically the old behavior) until most of them will get removed in a later release.

I'm on vacation and travelling at the moment, so it might take a few days until I find time for the implementation.