Can we just have struct inheritence already?

John Colvin john.loughran.colvin at gmail.com
Fri Jun 14 08:32:12 UTC 2019


On Friday, 14 June 2019 at 01:46:40 UTC, Timon Gehr wrote:
> On 14.06.19 02:15, Jonathan M Davis wrote:
>> Well, I fail to see how allowing access to private data is not 
>> @safe, since
>> it does not inherently mean that there are going to be 
>> problems with memory
>> safety.
>
> int[N] array;
> static assert(0<N);
>
> struct VerifiedIndex{
>     private int index_=0;
>     @disable this(int); // shouldn't be necessary, but it is
>     @property int index()@safe{ return index_; }
>     @property void index(int i)@trusted{ // no, this can't be 
> @safe
>         enforce(0<=x&&x<N, "index out of bounds");
>         index_=i;
>     }
>     int read()@trusted{ return array.ptr[index]; }
>     void write(int x)@trusted{ array.ptr[index]=x; }
> }
>
> This kind of thing is necessary. You need to give @trusted a 
> chance to provide a @safe interface. This is very hard if all 
> @safe code can randomly assign to your private members.

X.tupleof in context C should be @system where X has members not 
otherwise visible from C (e.g. private from a different module, 
package from the wrong package). In other cases, it's @safe.


More information about the Digitalmars-d mailing list