Why can't we derive struct's? (Hansel & Gretel)

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu Dec 27 20:15:04 UTC 2018

On Friday, December 21, 2018 4:28:21 AM MST Walter Bright via Digitalmars-d 
> On 12/20/2018 11:23 PM, Manu wrote:
> > and occasionally multiple implicit conversions.
> Another feature that looks great in the small, but turns into a hopeless
> morass all too quickly. Even C++ gave up on that, which meant it was
> pretty bad :-)
> (Basically, nobody could figure out which overload was being called and
> why.)

Honestly, over time, I've come to dislike implicit conversions more and
more. They cause enough stray bugs with the built-in types without even
getting into the issues with user-defined types (issues with implicit
conversions with character type and implicit slicing of static arrays come
to mind in particular, though the problem is by no means just with them).
But what gets particularly bad is templated code. It's trivial to write code
that's supposed to work on any type that implictly converts to a particular
type but then fail to actually do the conversion in the code, resulting in
subtle bugs. The primary fix for this is to _always_ force the conversion if
you're writing templated code that is supposed to work with an implicit
conversion, but in general, it just works better that the conversion occur
outside of the template. So, taking all of that into account, it becomes
easy to start viewing implicit conversions in general as being a terrible

That being said, there are definitely times where implicit conversions are
nice to have, and not having them can get pretty annoying. Also, casting is
a blunt enough instrument that it can become easy to end up having explicit
conversions that do the wrong thing (especially if the types involved get
changed later without the code involving the case being updated). So,
echewing implicit conversions can cause other problems (though on the whole,
I do think that explicit conversions have far fewer problems - they just can
get annoying sometimes).

But over time I've become increasingly worried about having the ability to
have multiple alias this-es on a type. There's no question that there are
times when it would be really useful, but with all of the problems
surrounding even a single alias this, having multiple alias this-es on a
type starts looking really risky. As it is, I think that having even a
single alias this should be done with caution and relatively rarely. And if
we had the ability to have multiple alias this-es on a type, I would think
that it should be used extremely rarely. But the very fact that it existed
could have some nasty repercussions (especially for generic code). I don't
know that that means that we shouldn't have the feature, but it definitley
concerns me.

- Jonathan M Davis

More information about the Digitalmars-d mailing list