Should modifying private members be @system?

Dennis dkorpel at gmail.com
Fri Oct 4 12:49:48 UTC 2019


On Friday, 4 October 2019 at 12:37:26 UTC, Jonathan M Davis wrote:
> However, if a member function is marked @trusted, then it's up 
> to the programmer to ensure that it's guaranteed to be @safe in 
> spite of whatever @system operations it's doing, and if that 
> function relies on the member variables being in a particular 
> state, and that state cannot actually be guaranteed, because 
> the member variables are public and could have been messed 
> with, then it's inappropriate to mark the function as @trusted.

I agree totally. I'm looking for ways to give @trusted code 
writers guarantees that certain variables haven't been messed 
with, because writing @trusted code without any access to state 
is crippling the possibilities. With the recent push for @safe 
manual memory management [1] I'm expecting this to become an 
issue. (As mentioned before, how are you going to do safe 
reference counting when you can't rely on the reference count to 
be correct?)

[1] 
https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/


More information about the Digitalmars-d mailing list