.tupleof sidesteps protection attributes

[dlangBugzillaToGithub]

Simen Kjaeraas reported this on 2018-10-22T14:08:26Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=19326

CC List

• Walter Bright (@WalterBright)
• Jacob Carlborg (@jacob-carlborg)
• Peter Alexander (@Poita)
• RazvanN

Description

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

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2018-10-22T18:47:00Z

I don't consider this a bug, I consider this a feature.

[dlangBugzillaToGithub]

bugzilla (@WalterBright) commented on 2018-10-22T23:33:02Z

tupleof is known to break through private access protections. It should probably not be allowed in @safe code.

[dlangBugzillaToGithub]

peter.alexander.au (@Poita) commented on 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.

[dlangBugzillaToGithub]

razvan.nitu1305 commented on 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?