Beta D 2.071.2-b3

Rory McGuire via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Fri Sep 2 00:46:30 PDT 2016


On Fri, Sep 2, 2016 at 8:47 AM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce at 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20160902/bff2a17d/attachment.html>


More information about the Digitalmars-d-announce mailing list