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

[Carl Sturtivant]

On Wednesday, 7 February 2024 at 21:42:17 UTC, Walter Bright 
wrote:
> On 2/6/2024 2:17 AM, Atila Neves wrote:
>> Sure, this would definitely help. I think the lesson learned 
>> there is that implicit conversions *by default* are a bad 
>> idea. I don't even like integer conversions, cast if you want 
>> it.
>
> If this only impacted the person who wrote the code, that would 
> be ok. But these sorts of things have their way of insidiously 
> infecting large code bases long after the guy who wrote it has 
> gone.

I don't think this kind of concrete experience-based pattern 
matching fits the actual logical details of the situation. The 
above is a not reason to block @implicit.

@implicit would have to be used deliberately, i.e. it's opt-in 
not there by default. Any language feature can be abused. 
Blocking all conversions for parameter passing has the effect of 
blocking sane uses of conversions added deliberately.

For example it blocks sane aspects of any sum type and any analog 
of Variant.

> For example, macros and version algebra have caused endless 
> suffering of maintainers who have no say in what the dear 
> departed originator did. I've even known of a couple cases 
> where the entire codebase was scrapped because of it.

In many many respects @implicit is not at all like these. Please 
put this aside and consider the notion of @implicit on its 
logical merits.

> However, I understand that sumtypes can make good use of 
> implicit conversions. I'm working on a language proposal to 
> enable that by making sumtypes a language feature in and of 
> itself.

@implicit would enable a solution in D with no fuss.

A sum type in the language that cannot be implemented in D would 
seem to be a serious breach of the D philosophy. In a discussion 
of built-in types versus user defined types TDPL's operator 
overloading chapter (p.365) lists 3 aspects of built-ins that D 
takes advantage of. None are relevant here. There's no good 
reason it is impossible to make a sum type in D that works as 
reasonably expected.

I hope you will consider changing your mind about completely 
blocking @implicit and instead consider that it solves a lot of 
problems, without operating by default, and accept that it is a 
positive thing to add to D.