On 02 Sep 2016 07:40, "ketmar via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> 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.
>
>
> 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!

Perhaps @system code should just completely ignore privacy? Could have a compiler option that changes the access errors into warnings?

Then make a separate tool that we can use to do assertions on that code. For example or company could have a policy that any @system code has 100% test coverage.

Just thinking it loud.

R

On Friday, 2 September 2016 at 06:27:11 UTC, Rory McGuire wrote:
> Perhaps @system code should just completely ignore privacy?

it is uncontrollable. imagine attribute inference: today, your function was inferred @system, and it sees everything. and tomorrow you fixed some other things, and now your function inferred as @safe. BOOM! without warning, it doesn't do what it does before (but still works!), and you didn't even touched it's code. this is the worst kind of breakage.

> Could have a compiler option that changes the access errors into warnings?

each compiler option of this kind means "we failed our design task, brought you the feature that is so unusable that we even made it possible to turn it off globally. sorry, we giving up, now it is up to you to clean up the mess after us."

On Fri, Sep 2, 2016 at 8:47 AM, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 2 September 2016 at 06:27:11 UTC, Rory McGuire wrote:
>
>> Perhaps @system code should just completely ignore privacy?
>>
>
> it is uncontrollable. imagine attribute inference: today, your function was inferred @system, and it sees everything. and tomorrow you fixed some other things, and now your function inferred as @safe. BOOM! without warning, it doesn't do what it does before (but still works!), and you didn't even touched it's code. this is the worst kind of breakage.


I'm meaning if the dev marks the whole module as @system. I'm not convinced that _any_ code should ever be inferred as @system. Its not okay for people to accidentally make @system code.


>
>
> Could have a compiler option that changes the access errors into warnings?
>>
>
> each compiler option of this kind means "we failed our design task, brought you the feature that is so unusable that we even made it possible to turn it off globally. sorry, we giving up, now it is up to you to clean up the mess after us."
>

You may have a point there, even if its a bit excessive. I would like this as a pragma, but then that leads us down the road of not even bothering to change the compiler and just use a analysis tool.

mmm, even if we did make private access illegal we can still access whatever we want if we have the source code so...

e.g. mixin(import(moduleName!exampleSymbol).replace("private", "public"));

not sure it would always work...

On Friday, 2 September 2016 at 07:46:30 UTC, Rory McGuire wrote:
actually, from my PoV solution is supereasy: just remove ALL visibility restrictions for traits. and i mean all. allMembers should return all members, getMember should allow to access *any* existing member without annoying messages. it is up to programmer to insert getProtection checks if he needs it.

traits is a low-level feature by definition, and doesn't meant to be used directly (we have std.traits wrappers for that), so i want D devs to stop making our, low-level coders, life harder than it is now. ;-)

D devs just should draw the line between __traits and std.traits. first sould be inherently unsafe, allow *everything* and impose as little restrictions as it is possible (note: *as* *possible*, not *as* *sane* -- all kind of insanity should be allowed, if it is possible). then, std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end).

On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
> std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end).

This has nothing to do with memory safety. It's just that protection attributes were invented for OOP and when applied to template meta programming they suck a bit.

On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
> On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
>> std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end).
>
> This has nothing to do with memory safety.

i wonder who told you that @safe code is *only* about "memory safety".

On Fri, Sep 2, 2016 at 10:15 AM, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 2 September 2016 at 07:46:30 UTC, Rory McGuire wrote:
> actually, from my PoV solution is supereasy: just remove ALL visibility
> restrictions for traits. and i mean all. allMembers should return all
> members, getMember should allow to access *any* existing member without
> annoying messages. it is up to programmer to insert getProtection checks if
> he needs it.
>
> traits is a low-level feature by definition, and doesn't meant to be used directly (we have std.traits wrappers for that), so i want D devs to stop making our, low-level coders, life harder than it is now. ;-)
>
> D devs just should draw the line between __traits and std.traits. first sould be inherently unsafe, allow *everything* and impose as little restrictions as it is possible (note: *as* *possible*, not *as* *sane* -- all kind of insanity should be allowed, if it is possible). then, std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end).
>


May our benevolent dictators agree with you :D (I do).

If a developer is willing to research the language definition and discover __traits, you should be ready for unprotected intimacy with the hardware of your choice. And if someone just copy pastes code with __traits in it they should know that "__" in a symbol is a "WARNING here be dragons"

On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
> On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
>> std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end).
>
> This has nothing to do with memory safety.

Actually it does, albeit somewhat tangentially: Accessing private members from the outside must be @system since the @trusted implementation of a class might rely on nobody meddling with the private state.

 — David

On Fri, 02 Sep 2016 09:40:56 +0000, ketmar wrote:

> On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
>> On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
>>> std.traits wrappers should use __traits to build *safe* things
>>> (declaring that @trusted in the end).
>>
>> This has nothing to do with memory safety.
> 
> i wonder who told you that @safe code is *only* about "memory safety".

Walter Bright, when @safe was being discussed, before it was implemented.

On Friday, 2 September 2016 at 10:29:41 UTC, David Nadlinger wrote:
> On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
>> On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
>>> std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end).
>>
>> This has nothing to do with memory safety.
>
> Actually it does, albeit somewhat tangentially: Accessing private members from the outside must be @system since the @trusted implementation of a class might rely on nobody meddling with the private state.
>
>  — David

The essence of the problem is that an aggregate cannot fully introspect itself using a template located in another module. If the @system constraint is only for the private members then it's ok.