On Monday, 5 February 2024 at 09:04:23 UTC, Atila Neves wrote:
> On Saturday, 3 February 2024 at 03:19:00 UTC, Walter Bright wrote:
>> C++ has this, implicit conversion of structs. It looks great with simple cases. However, as overloading gets more complex, it becomes a source of mass confusion. I've had many C++ programmers tell me that nobody actually knows how C++ overloading works - they just try random things until they get the result they want. There was a lot of talk in the 90s about implicit conversion being a mistake, but by then it was too late and C++ has had to learn to live with it.
>>
>> It's in that class of features that inevitably lead to incomprehensible code.
>>
>> I tried to make overloading in D much simpler, but it's still overly complex.
>>
>> Let's not dig that cat out of the pet semetary.
>
> It got bad enough in C++ that the guideline is now to use explicit on single parameter constructors: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-explicit

I just don't think that "this feature can be abused" is a convincing argument. So what? Make it opt-in, mark it as dangerous, then when people use it it's on them.

I don't want implicit conversion to always be enabled, I want it to be enabled by a keyword or UDA. @implicit or something. Even per-parameter would be useful!

Honestly, if you just hardcoded implicit construction for `std.sumtype.SumType` I would be quite happy already.

On Tuesday, 6 February 2024 at 10:10:32 UTC, FeepingCreature wrote:
> On Monday, 5 February 2024 at 09:04:23 UTC, Atila Neves wrote:
>> On Saturday, 3 February 2024 at 03:19:00 UTC, Walter Bright wrote:
>>> [...]
>>
>> It got bad enough in C++ that the guideline is now to use explicit on single parameter constructors: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-explicit
>
> I just don't think that "this feature can be abused" is a convincing argument. So what? Make it opt-in, mark it as dangerous, then when people use it it's on them.
>
> I don't want implicit conversion to always be enabled, I want it to be enabled by a keyword or UDA. @implicit or something. Even per-parameter would be useful!

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.

> Honestly, if you just hardcoded implicit construction for `std.sumtype.SumType` I would be quite happy already.

Something I've wanted every time I've used it.

On 06/02/2024 11:17 PM, Atila Neves wrote:
> On Tuesday, 6 February 2024 at 10:10:32 UTC, FeepingCreature wrote:
>> On Monday, 5 February 2024 at 09:04:23 UTC, Atila Neves wrote:
>>> On Saturday, 3 February 2024 at 03:19:00 UTC, Walter Bright wrote:
>>>> [...]
>>>
>>> It got bad enough in C++ that the guideline is now to use explicit on single parameter constructors: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-explicit
>>
>> I just don't think that "this feature can be abused" is a convincing argument. So what? Make it opt-in, mark it as dangerous, then when people use it it's on them.
>>
>> I don't want implicit conversion to always be enabled, I want it to be enabled by a keyword or UDA. @implicit or something. Even per-parameter would be useful!
> 
> 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.
> 
>> Honestly, if you just hardcoded implicit construction for `std.sumtype.SumType` I would be quite happy already.
> 
> Something I've wanted every time I've used it.

+1 to all of this.

The implicit conversion wouldn't be too hard to implement either.

I actually implemented an implicit conversion today, in preparation of sumtypes!

https://github.com/dlang/dmd/pull/16161

To make the following work:

```d
Enum varF2 = identity(:Middle);

Enum identity(Enum e) {
	return e;
}

enum Enum {
	Middle
}
```

On Tuesday, 6 February 2024 at 10:10:32 UTC, FeepingCreature wrote:
> I just don't think that "this feature can be abused" is a convincing argument. So what? Make it opt-in, mark it as dangerous, then when people use it it's on them.
>
> I don't want implicit conversion to always be enabled, I want it to be enabled by a keyword or UDA. @implicit or something. Even per-parameter would be useful!

+1

@implicit

Exactly what's needed under the present circumstances. Naive scripting with Variant could then work out of the box, for example, instead of being completely blocked.

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.

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.

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.

On 08/02/2024 10:42 AM, 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.
> 
> 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.
> 
> 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.

Yeah, its basically just a foreach in ``callMatch``.

Then do the rewrite for real in ``functionParameters``.

Of course I'm not happy with your design, hence I made the following PoC PR to solve specifying names without the type :)

https://github.com/dlang/dmd/pull/16161

On 2/7/2024 2:20 PM, Richard (Rikki) Andrew Cattermole wrote:
> Of course I'm not happy with your design

LOL

On 08/02/2024 11:40 AM, Walter Bright wrote:
> On 2/7/2024 2:20 PM, Richard (Rikki) Andrew Cattermole wrote:
>> Of course I'm not happy with your design
> 
> LOL

Yes, I think its mostly the member of operator + some fleshing out.

The implicit conversion was something we differed upon, but looks like we're converging there.

I'm hopeful that I'm not going to have to write a DIP ;)

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.