module foo;
struct S {
private int i;
}
----
module bar;
import foo;
@safe unittest {
S s;
// Fails: struct `foo.S` member i is not accessible
s.i++;
// Fails: struct `foo.S` member i is not accessible
__traits(getMember, s, "i")++;
// Compiles just fine:
s.tupleof[0]++;
}
This breaks guarantees about what's accessible from other modules, and can be used to break invariants relied on in @trusted code.
At the very least, this should not be @safe.
Related: issue 15371
Comment #1 by doob — 2018-10-22T18:47:00Z
I don't consider this a bug, I consider this a feature.
Comment #2 by bugzilla — 2018-10-22T23:33:02Z
tupleof is known to break through private access protections. It should probably not be allowed in @safe code.
Comment #3 by peter.alexander.au — 2018-10-22T23:55:50Z
It probably goes without saying, but many parts of Phobos use tupleof, so a generously sprinkling of @trusted would be needed. Likely this will break much 3rd party code although that is pure speculation on my part.
Comment #4 by razvan.nitu1305 — 2023-04-28T10:53:18Z
It seems that now `__traits(getMember, s, "i")++;` also compiles. Does that mean that tupleof is also allowed or should we change this?
Comment #5 by robert.schadek — 2024-12-13T19:01:00Z