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

On Sun, Jun 04, 2017 at 08:15:46PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote:
> 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++.

So D has plenty of implicit conversion. It is implicit *construction* that it lacks.

And alas, C++'s mistake is implicit is default, so it gets used in places it wasn't intended. We should have just had explicit default with implicit as an option.

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.