What is the reasoning behind the lack of conversions when passing parameters

[Jonathan M Davis]

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
>
> wrote:
> > 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