|Posted by Jonathan M Davis
in reply to Carl Sturtivant
Posted in reply to Carl Sturtivant
On Friday, February 2, 2024 4:49:21 PM MST Carl Sturtivant via Digitalmars-d wrote:
> On Friday, 2 February 2024 at 22:02:30 UTC, Jonathan M Davis
> > However, I'm pretty sure what it comes down to is that it simplifies function overloading (which can get fairly complex in C++ thanks to it allowing such conversions).
> Those complications could have been embraced *because* parameter passing and initialization are best kept to exactly the same semantics when there is no overloading. And that would force a system of overloading compatible with such that extends naturally when an additional function of the same name is added, that works without changing the semantics of the others. C++ can do it. So D can.
> Overloading is complicated anyway, so pushing the complications into there rather than crippling parameter passing is making the language more effective. Scripting naively with Variant from std.variant would just work for example.
I really don't see how this is crippling anything, but then again, I'd be perfectly fine with requiring explicit constructor syntax when initializing a variable. It's how I program anyway.
> > It also reduces the number of bugs that you get from implicit conversions (though we do have alias this). By having alias this without the implicit construction with function arguments, we make it so that the conversion is only in one direction, whereas if we also allowed conversion based on constructors, then it would complicate the choices considerably in some cases.
> Why is `alias this` conversion permitted with parameter passing? Why isn't the no conversion restriction applied there? Your 'not onerous' argument below could be applied, and the name from the `alias this` declaration could have to be explicitly used. And that would affect only types that have alias this, not *everything* which is what the current restriction affects. Seems like the wrong decision.
Well, personally, I'd actually be in favor of removing alias this entirely, because I think that implicit conversions like it are usually a mistake (and they definitely cause problems with templated code), but I'm sure that there would be complaints about it, since there are cases where it can be useful, and some folks like being able to do it. However, my experience in general is that implicit conversions are a source of bugs and best avoided, much as they can occasionally be useful.
Regardless, I explained to you what was my understanding of why things work the way that they do. For better or worse, Walter made a number of choices like this that tried to simplify the situation in comparison to C++. Obviously, some stuff became impossible as a result, and some folks aren't going to like that, but you'll have to take that up with Walter.
Personally, I've dealt with function overloading involving constructors in C++, and I've dealt with the situation in D, and I find the result in D to be far easier to understand without being a problem. So, I'm inclined to think that D made the right choice, but not everyone is going to agree with that.
- Jonathan M Davis