Can we just have struct inheritence already?

[Nicholas Wilson]

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.

Alas, memory safety is not an easy beast to pin down. If it were, 
we wouldn't be having this conversation.

>> If you have a race condition on a pointer write, and that 
>> write corrupts memory, then that is a memory safety bug that 
>> is also a thread safety bug.
>>
>> In the world of multithreading, memory safety and thread 
>> safety are _not_ separable.
>>
>> I know because we'e had a bug exposed by LDC breaking such 
>> optimisation that relied on that.
>
> There's certainly a reasonable case for trying to support 
> constraints that rule out undefined behaviour, but let's make 
> that case in the understanding that we're asking for something 
> new, not something that was always intended to be part of the 
> language spec.

Sure, but whatever happens, I don't think there's any future in 
saying "@safe code guarantees that no memory corruption will 
occur except if a) there is a bug in your @trused code (your 
fault) b), the compiler (our fault) or c) you write through a 
stale cached pointer,through a race condition or somehow else 
(tough luck)".

For sure the status quo is vastly superior to nothing, but memory 
safety doesn't stop with the current implementation.