shared - i need it to be useful

Walter Bright newshound2 at digitalmars.com
Mon Oct 22 23:39:37 UTC 2018


On 10/22/2018 7:31 AM, Timon Gehr wrote:
> Even if this is changed (and it probably should be), it does not fix the case 
> where the @safe function is in the same module. I don't think it is desirable to 
> change the definition of @trusted such that you need to check the entire module 
> if it contains a single @trusted function.
> 
> If I can break safety of some (previously correct) code by editing only @safe 
> code, then that's a significant blow to @safe. I think we need a general way to 
> protect data from being manipulated in @safe code in any way, same module or not.

One possible workaround is to use PIMPL. Another is to put the @trusted privates 
in a separate module.

The rationale behind module access to privates is:

1. avoid the whole ugly C++ "friend" complexity

2. presumably someone with privileges to edit a module can be trusted to behave

3. the module is the level of encapsulation


More information about the Digitalmars-d mailing list