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