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