Can we just have struct inheritence already?

Manu turkeyman at gmail.com
Tue Jun 11 00:49:32 UTC 2019


On Mon, Jun 10, 2019 at 5:35 PM Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 6/10/2019 3:56 PM, Manu wrote:
> > Uninitialised data, which is guaranteed to have no valid state, and
> > has absolutely no chance of proper program execution under any
> > circumstance, and may even be leaking internal/private state(!), is
> > not safe. You can't convince me otherwise.
>
> It is memory safe. It's a fact, not an opinion.

Consequence may not be. Effect isn't necessarily isolated to this statement.
And you'll retort that that's true for every line of code, even well
formed code... but in this case, we can guarantee without any shadow
off doubt that a program error probably exists, and I want @safe to
mean that.

It also leaks private knowledge, and it's the first place anyone would
look to exploit your code. If @safe doesn't do everything it can to
assist preventing that sort of attack, especially something so plainly
obvious, then it's not doing its job.

> If you want @safe to mean "no undefined behavior", that is a valid opinion, but
> that is not what @safe in D is currently defined as.

Well it's an unsatisfying or incomplete definition then if it allows
for something so obviously unsafe (in english terms) to be considered
perfectly fine.

> > Occasionally argument improves outcomes, but for the most part, we're
> > all just wasting time here.
>
> Saying "you can't convince me otherwise" guarantees discussing things won't
> work. :-)

Right. That's my point. And why I said we shouldn't pull this off topic.
If your definition of safe doesn't allow for the compiler to issue an
error when accessing provably invalid memory, then I don't care for
your definition of @safe.
Users tend not to be language lawyers, they will be surprised by this.

Anyway, that's not on trial here.


More information about the Digitalmars-d mailing list