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

[Steven Schveighoffer]

On 12/27/18 3:15 PM, Jonathan M Davis wrote:
> On Friday, December 21, 2018 4:28:21 AM MST Walter Bright via Digitalmars-d
> wrote:
>> 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.)

We don't have to copy what C++ did.

> 
> 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
> idea.

Well, implicit conversions of builtin types is not something a mere user 
can fix. I'd love to fix those problems, but the one DIP that was trying 
to fix a minuscule part of that was rejected for reasons that don't bode 
well for other parts.

But in terms of implicit casting that's user defined -- those things are 
fixable (if they are a problem).

Quite honestly, if alias this didn't exist, wrapping a type would be 
monstrously difficult. But it has to be implemented correctly (it's not 
right now).


> 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).

Speaking of that, I believe it's possible to have a casting library that 
is similar to C++'s casting system. We should create one.

> 
> 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.

Having multiple alias this's would not increase any of the existing 
problems really, it just would add one more wrinkle of ambiguity. But I 
think that behavior should be easily defined and understood.

As for my own experience, I can't see myself using multiple alias this 
much at all, but it's definitely something that seems like an artificial 
limitation.

-Steve