On Saturday, 3 February 2024 at 00:23:59 UTC, bachmeier wrote:
> I've long hated this inconvenience. It could be solved without a language change by putting something like this in Phobos (I've never actually written the code):

You may find something you could use here.
https://forum.dlang.org/post/shlldocweumneexbeuqx@forum.dlang.org

On Saturday, 3 February 2024 at 17:58:22 UTC, Walter Bright wrote:
> P.S. Overloading is often used excessively, even in the DMD source code.

I wonder why overloading doesn't need an `overload` keyword at the site of an overloaded function definition.

After all, it's about a situation where the possible repertoire of functions that could be called at the site of a function call is extended.

This is much like `override` when a method call's repertoire is extended.

This last design decision is great because it makes overt what's going on at the textual point where new code is being written. The compiler ensures the author knows about the interaction with existing code.

No doubt there are some ramifications to having an `overload` keyword with the obvious semantics. But the general effect would be to discourage overloading so that its use is an overt decision.

Was the idea of an `overload` keyword ever considered for D?

On Saturday, 3 February 2024 at 18:53:02 UTC, Carl Sturtivant wrote:
> 
> Was the idea of an `overload` keyword ever considered for D?

What do you have against overloading?

Breaking overloading would kill d, just unironically; how templates even exist is fundamentally about overloading, and the rabbit hole of overloading is rich and wonderful.

I want function overloading to be 90% of all features in a language; and what auto-promotion rules d has is already to much and breaks overloading for example an overload set containing `foo(int[3])` and `foo()(string)` when matched to `foo("foo")` or something like it matches insanely to the int[3] in some cases.

If you want a highly polymorphic function grab some of the example metaprogramming code and just alias

On 2/3/2024 10:53 AM, Carl Sturtivant wrote:
> Was the idea of an `overload` keyword ever considered for D?

It never occurred to anyone.

On Saturday, 3 February 2024 at 18:53:02 UTC, Carl Sturtivant wrote:
> ...
> This last design decision is great because it makes overt what's going on at the textual point where new code is being written. The compiler ensures the author knows about the interaction with existing code.
>
> ...

I like this principle, that the compiler 'ensures' the author knows about
the interaction with existing code.

The interaction of code in D, is not always clear. It's the downside of C too.

For a modern 21st century PL, there are surely improvements that can be made in this area.

Unfortunately, they will inevitably come at a cost - just as they would in C.

D is very much attached to C. One should always keep that in mind - in your code that is.

On Saturday, 3 February 2024 at 23:04:39 UTC, monkyyy wrote:
> Breaking overloading would kill d, just unironically; how templates even exist is fundamentally about overloading, and the rabbit hole of overloading is rich and wonderful.

Good point about templates.

I just have a sense that there is some hidden simplicity that has not been found in the present design.

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

On Saturday, 3 February 2024 at 18:53:02 UTC, Carl Sturtivant wrote:
> On Saturday, 3 February 2024 at 17:58:22 UTC, Walter Bright wrote:
>> P.S. Overloading is often used excessively, even in the DMD source code.
>
> I wonder why overloading doesn't need an `overload` keyword at the site of an overloaded function definition.

What D does is "implicit" overload creation. If the same name already exists in the current scope it just creates an "overload set", adding possible candidates in a sort of linked list. There are restrictions however on what can be part of a set, for example you cannot overload a function declaration with an int declaration.

However this becomes complicated when it's about eponymous templates. There are probably still a couple of bugs related to that, because the way the semantics of a D program are checked does not allow to verify 100% of the time that the eponymous member(s) (yes plural) are all functions.

On Monday, 5 February 2024 at 19:16:40 UTC, Basile B. wrote:
> On Saturday, 3 February 2024 at 18:53:02 UTC, Carl Sturtivant wrote:
>> [...]
>
> What D does is "implicit" overload creation. If the same name already exists in the current scope it just creates an "overload set", adding possible candidates in a sort of linked list. There are restrictions however on what can be part of a set, for example you cannot overload a function declaration with an int declaration.
>
> However this becomes complicated when it's about eponymous templates. There are probably still a couple of bugs related to that, because the way the semantics of a D program are checked does not allow to verify 100% of the time that the eponymous member(s) (yes plural) are all functions.

If you like, the way sets are created is cristal-clear but the way a member of the set is picked is more complex ;)