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