Should modifying private members be @system?

Dennis dkorpel at gmail.com
Fri Oct 4 12:34:46 UTC 2019


On Friday, 4 October 2019 at 12:13:29 UTC, ag0aep6g wrote:
> My best idea so far (might not be originally mine) is to let 
> the @system attribute apply to variables. You'd mark `_length` 
> as @system and the effect would be that @safe functions would 
> not be allowed to access it.

I like that idea a lot more! It wouldn't be arbitrary and code 
breaking.

> You're not marking the module as @trusted. You're marking 
> opIndex. When you justify @trusted with something outside the 
> marked function, you're misusing it.

In this case it's a member function. A common pattern is to put 
unsafe parts of a function in a block like this:
() @trusted {/*do something unsafe*/} ()

Such a lambda cannot be @trusted unconditionally, it's trusted 
because it is known it can only be called in its context and not 
outside the outer function's scope. My broader question is 
whether the language can be designed so member functions can rely 
on certain assumptions. Currently writing proper @trusted code is 
extremely hard because it is unknown what you can work with.

- does const give any guarantees? (afaik, yes)
- does pure give any guarantees? (no, you can return 
`cast(size_t) (new int)`)
- does private give any guarantees? (currently not, but it could)

> Unfortunately, breaking the rules like this is rather common. 
> But it's still breaking the rules. It's still undermining @safe.

So with @system members, can we give any guarantees of integrity 
to member functions?




More information about the Digitalmars-d mailing list