Can we just have struct inheritence already?

[H. S. Teoh]

On Wed, Jun 12, 2019 at 12:31:24AM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 6/10/19 7:00 PM, H. S. Teoh wrote:
> > On Mon, Jun 10, 2019 at 06:35:16PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> > > 
> > > Would it really be a problem for the addresses of zero-byte
> > > structs to just simply be null?
> > 
> > Probably, if people expect:
> > 
> > 	struct S {}
> > 	S s;
> > 	assert(&s !is null);
> > 
> > to work.
> 
> Ehh, maybe, but since when does anyone ever check a D struct's address
> for being null?

I wouldn't say it occurs to structs specifically, but in generic code,
it's conceivable you'd want to receive pointers and check whether
they're actually pointing to something or if there's no value (e.g.,
using null as a kind of absence-of-data indicator).  There might be
unexpected interaction with code that uses null for indicating, e.g.,
whether a container slot exists, which becomes problematic if null is
also the address of an instance of a 0-sized type (thereby conflating
"non-existent slot" with "slot exists but data is 0 bytes).

This is kinda contrived, though, and honestly I would vote for not
supporting this sort of usage.  But it's the kind of thing certain
people might get up in arms about, if this behaviour were changed.


> Or, heck, even just have it share an address with another data member.
> That or the null thing, I see no realistic problem either way. Or if
> you really want to be needlessly clumsy about it, have an attribute or
> pragma or something that says "If this field is a zero-byte struct,
> then for the love of god make it zero byte, I don't even care how you
> do it."

Maybe just alias it to void[0], like somebody proposed?


> I really don't like the whole "ships have sailed" theme in D though.
> It just gives a straight up middle finger to "The Last Thing D Needs"
> and to the whole reason for D's creation in the first place - to fix
> stupid legacy mistakes.

Personally, I agree that we shouldn't shy away from breaking changes if
it improves the language for the long term.  After all, that's what the
deprecation process is for.  But I'm not holding my breath for D
leadership to buy into this sort of breaking change.


> And yea, sure, of course we have bigger fish to fry. But that should
> never be a reason to say "The mistake is realistically fixable, but
> NO, never gonna anyway!" instead of "Right, that was a mistake and
> it's fixable. We should fix it sooner or later BUT it's not a high
> priority right now."

In fact, I agree.  But I'm also not holding my breath for D leadership
to change this attitude anytime soon. Cf. the bool fiasco, the char ->
int implicit conversion (C promotion rules) fiasco, autodecoding (which
is by now universally acknowledged as a mistake, but nobody has yet
dared to take the first step to actually kill it), etc..

At some point, I seriously want to entertain the idea of D3. It used to
be immediately shot down as not being likely, but with Andrei's recent
change of stance about std.v2, there's a faint glimmer of hope that
perhaps one day D3 could become reality.


T

-- 
Gone Chopin. Bach in a minuet.