Can we just have struct inheritence already?

Manu turkeyman at gmail.com
Thu Jun 13 23:30:43 UTC 2019


On Thu, Jun 13, 2019 at 4:12 PM Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Thursday, June 13, 2019 4:27:46 PM MDT Manu via Digitalmars-d wrote:
> > On Thu, Jun 13, 2019 at 7:35 AM Nemanja Boric via Digitalmars-d
> >
> > <digitalmars-d at puremagic.com> wrote:
> > > On Thursday, 13 June 2019 at 13:32:05 UTC, Joseph Rushton
> > >
> > > Wakeling wrote:
> > > > On Thursday, 13 June 2019 at 08:24:38 UTC, Nicholas Wilson
> > > >
> > > > wrote:
> > > >> No: the spec disagrees with the implementation, therefore at
> > > >> least one of them is wrong. It does not immediately follow
> > > >> that it is the spec that is in error.
> > > >
> > > > It's reasonable to say in this case that the spec is in error,
> > > > because Walter has always been 100% clear that @safe refers
> > > > only to memory safety, and the implementation reflects that
> > > > intent.
> > >
> > > Not really:
> > >
> > > https://issues.dlang.org/show_bug.cgi?id=19326
> > >
> > > > tupleof is known to break through private access protections.
> > > > It should probably not be allowed in @safe code.
> >
> > Wait... what?
> > "tupleof is known to break through private access protections. It
> > should probably not be allowed in @safe code." - Walter Bright
> >
> > Breaking private access is not in any way shape or form a memory
> > safety violation.
>
> Agreed. It might make it possible to then screw up the memory in an object,
> but that code would then have to be @trusted. And if it didn't actually
> doing anything that could screw with the memory of the object, then
> requiring that it be @trusted makes no sense.

To be clear, I'm not disagreeing with Walter; I agree with him. I'm
just pointing out that his position is inconsistent, and this quote is
correct. But you have to accept that if this quote is correct, then `=
void` shouldn't be @safe either.


More information about the Digitalmars-d mailing list