Can we just have struct inheritence already?

[Jonathan M Davis]

On Thursday, June 13, 2019 5:30:43 PM MDT Manu via Digitalmars-d wrote:
> 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.

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. There are reasons to be unhappy about the access level being
ignored, but it isn't a memory safety issue until you actually do something
with the private data which isn't memory safe.

Whether = void is a memory safety problem or not should depend on whether it
can possibly result in memory being corrupted or not.

But if it it's being argued that it should be considered @safe when
assigning void to something like an integer, because it can't corrupt memory
even though it's bypassing the protections that the compiler normally gives
you, while it's simultaneously being argued that .tupleof should be
considered @system just because it's bypassing the protections that the
compiler normally gives you, then no, I wouldn't think that that position
would qualify as being consistent.

Regardless, IMHO, if @safe is specifically about memory safety, then that's
what it should be about. We shouldn't have anything considered @system when
the compiler can actually verify that it's memory safe.

- Jonathan M Davis