Can we just have struct inheritence already?
Jonathan M Davis
newsgroup.d at jmdavisprog.com
Thu Jun 13 22:17:04 UTC 2019
On Thursday, June 13, 2019 3:49:56 PM MDT Walter Bright via Digitalmars-d
wrote:
> On 6/13/2019 1:25 PM, Timon Gehr wrote:
> > On 13.06.19 09:27, Walter Bright wrote:
> >> The spec's wrong, because it doesn't do that.
> >
> > Memory safety implies no undefined behavior. The only way the spec can
> > be wrong [1] is if you say that corrupting memory has defined behavior
> > in D, in which case the spec would be too weak, and not too strong like
> > you are implying. Otherwise, "memory safe" and "no undefined behavior"
> > are equivalent.
> I've already agreed that an uninitialized int should have an undefined
> value, not undefined behavior :-)
>
> The spec does indeed lack precision with these terms, and it's something
> well worth addressing.
That doesn't change the fact that @safe code needs to disallow undefined
behavior. It just means that we need to be better about how things are
defined so that operations that don't need to be classified as having
undefined behavior aren't classifed as such, including specifying cases
where something has an undefined value but doesn't have undefined behavior.
So, while I think that the spec should be clarified to indicate that the
purpose of @safe is to guarantee memory safety rather than guaranteeing that
there's no undefined behavior, it still looks to me like it needs to require
that there be no undefined behavior in @safe code.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list