Make enum auto castable

[Mike B Johnson via Digitalmars-d-learn]

On Monday, 5 June 2017 at 03:15:46 UTC, Jonathan M Davis wrote:
> On Monday, June 05, 2017 02:14:14 Mike B Johnson via 
> Digitalmars-d-learn wrote:
>> On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote:
>> > On Monday, June 05, 2017 01:30:47 Mike B Johnson via
>> >
>> > Digitalmars-d-learn wrote:
>> >> [...]
>> >
>> > It's not a bug. The alias this conversion only goes one way. 
>> > It provides a way to convert _from_ the type that it's 
>> > declared on to another type, not from the other type to the 
>> > type that it's declared on. There is no way in D to declare 
>> > an implicit conversion in the direction you're trying. So, 
>> > if you have a struct that wraps an int like this, and you 
>> > want to assign it an int, you're going to need to explicitly 
>> > construct the struct - e.g. EnumX(1).
>> >
>> > - Jonathan M Davis
>>
>> That's pretty crappy! Defeats the whole point!
>
> Well, implicit conversions tend to cause a lot of bugs in C++ 
> code, so Walter decided to restrict them quite a bit more in D 
> than they are in C++. This therefore prevents a number of bugs 
> in D, but it also prevents implicit conversions from being used 
> in a number of situations where they're useful. Whether the end 
> result is better or worse, I don't know and certainly YMMV. As 
> it is, some of the implicit conversions that we still allow 
> have a tendency to cause bugs (e.g. conversions between 
> integral values and character types tend to be error-prone - 
> especially when arrays are involved - and using implicit 
> conversions with templated code is almost always a bad idea). 
> So, at times, I tend to think that all implicit conversions 
> should be banned. But at other times, it would be really nice 
> to be able to have more than we do (e.g. it would be a lot more 
> user-friendly if you could pass a T to a function that takes a 
> Nullable!T).
>
> In any case, I think that the reality of the matter with D is 
> that you tend to have to use explicit conversions rather than 
> implicit ones, and if you're looking to do much with implicit 
> conversions, you're usually going to be frustrated, and 
> obviously, that sucks, but at least you're less likely to have 
> bugs related to implicit conversions.
>
> - Jonathan M Davis

The problem is bugs are only a possibility. If you remove a 
feature from a language the feature does not exist, period.

So, throwing the baby out with the bath water because he pooped 
in it is not a solution.

Instead, if there is a problem with implicit autonomous 
conversion or construction, then the solution is not to remove 
all implicit conversions or constructions but to remove the 
autonomous part.

e.g., make the user specify the implicit conversion explicitly. 
This way, if bugs do creep in, it is due to the user. It is much 
easier to diagnose and fix then.