On 25.05.2016 01:19, Elie Morisse wrote:
> On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
>> Afaik free-function operator overloads (but not in the context of
>> UFCS) were considered and turned down because D did not want to get
>> amidst discussions about adding Koenig lookup. UFCS does not do Koenig
>> lookup.
>
> I don't get it, aren't the current symbol lookup rules enough to make
> free function operator overloads useful? To me it looks like they are.
> ...

Yup. It could be argued that it is essentially a compiler bug.

> Sorry for digging up this thread, just getting irritated by a
> restriction that seems pointless and arbitrary.
> ...

It is, but it has a few vocal proponents.

> Overloaded operators would suffer from the same potential abuses other
> methods are subjected to if UFCS was enabled, nothing more as far as I
> can see.

You are perfectly right of course. It's painful for no benefit. (For example, there's no way to overload e.g. '+=' for classes in a way that reassigns the reference.)

On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
> The difference is that it's impossible to do 10.opBinary!"+"(15), so if you're forced to do foo.opBinary!"+"(bar) to get around a symbol conflict, it won't work with built-in types.

Well, that begs the question: Why don't built-in types define `opBinary`? That's just another arbitrary irregularity, isn't it.

On Friday, May 27, 2016 09:08:20 Marc Schütz via Digitalmars-d-learn wrote:
> On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
> > The difference is that it's impossible to do
> > 10.opBinary!"+"(15), so if you're forced to do
> > foo.opBinary!"+"(bar) to get around a symbol conflict, it won't
> > work with built-in types.
>
> Well, that begs the question: Why don't built-in types define `opBinary`? That's just another arbitrary irregularity, isn't it.

It was never intended that any op* function be called by anyone except where the compiler lowers code to use them. They're for declaring overloaded operators on user-defined types so that those types can be used with those operators. If you're calling opBinary in your own code, you're doing it wrong. And it would be downright silly to then add opBinary to the built-in types. They don't need operator overloading. They already have the operators. Operators are supposed to be used as operators, not functions, and if there's any need to use them as functions, then there's something seriously wrong. And the fact that allowing free functions to overload operators via UFCS sends us into that territory just highlights the fact that they're a horrible idea.

- Jonathan M Davis

On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
> On Friday, May 27, 2016 09:08:20 Marc Schütz via Digitalmars-d-learn wrote:
>> On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
>> > The difference is that it's impossible to do
>> > 10.opBinary!"+"(15), so if you're forced to do
>> > foo.opBinary!"+"(bar) to get around a symbol conflict, it won't
>> > work with built-in types.
>>
>> Well, that begs the question: Why don't built-in types define `opBinary`? That's just another arbitrary irregularity, isn't it.
>
> It was never intended that any op* function be called by anyone except where the compiler lowers code to use them. They're for declaring overloaded operators on user-defined types so that those types can be used with those operators. If you're calling opBinary in your own code, you're doing it wrong. And it would be downright silly to then add opBinary to the built-in types.

If I were to design my own language from scratch, that's actually how I would do it. All operators, even for built-in types, would just be syntax sugar for the method calls. The goal should be to minimize the difference between built-in and user-defined types as much as possible. Turtles all the way down...

> They don't need operator overloading. They already have the operators. Operators are supposed to be used as operators, not functions, and if there's any need to use them as functions, then there's something seriously wrong. And the fact that allowing free functions to overload operators via UFCS sends us into that territory just highlights the fact that they're a horrible idea.

I'd say the fact that it doesn't work, and can't currently work for the reasons you described, points to an inconsistency in the language's design. It means that we have two largely overlapping concepts (builtin types and user defined types), where most language features work the same for both, but some don't.

That's not the end of the world, of course, but still...

Here's one more vote for extending UFCS to operator overloading. Elie wrote that it's "a restriction that seems pointless and arbitrary"... which summarizes my own thoughts rather well, too.

There are certainly concerning scenarios that can arise from making this change, but the correct way to approach this problem is not to tell the programmer "I won't let you use that tool, because if you mishandle it then you might find yourself in a nasty mess." That's what Java does - it treats the programmer like an idiot - and that's why it's so universally despised.

It has consistently been my impression that this is very much not the sort of philosophy D follows.

Anyway, D already provides the programmer with a wealth of tools which, if mishandled, can place them in a nasty mess. So I think this is a poor rationale for withholding from the programmer one more.

On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
> And the fact that allowing free functions to overload operators via UFCS sends us into that territory just highlights the fact that they're a horrible idea.
>
> - Jonathan M Davis

Do you have any examples of UFCS doing bad things? Most people seem to very much like it yet you argue against any change that would benefit UFCS.

You seem to prefer:

    read(to(easier(much(i)))) over i.much.easier.to.read

On Tuesday, May 31, 2016 14:11:58 ixid via Digitalmars-d-learn wrote:
> On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
> > And the fact that allowing free functions to overload operators via UFCS sends us into that territory just highlights the fact that they're a horrible idea.
> >
> > - Jonathan M Davis
>
> Do you have any examples of UFCS doing bad things? Most people seem to very much like it yet you argue against any change that would benefit UFCS.
>
> You seem to prefer:
>
>      read(to(easier(much(i)))) over i.much.easier.to.read

The primary benefit of UFCS is that you can write generic code that will work with both member functions and free functions, allowing you to have a free function that does something and a member function that does that same thing more efficiently for that specific type (a prime example of this would be a function like find where a linear search make sense in most cases but wouldn't for certain data structures - e.g. a sorted, binary tree). So, the "universal" aspect of UFCS is important for generic code, whereas it would be completely unnecessary if the code weren't generic. All of the other benefits of UFCS are highly subjective and have to do with what a particular person thinks is easier or harder to read rather than actual, technical benefits (though obviously writing code in a way that is easier to read for those working on it is obviously valuable). Personally, I've dealt with functional languages enough that I've never felt that UFCS was much of an improvement syntactically. But we have it, and anyone is free to use it or not as they see fit.

Regardless, what I'm arguing against here is altering operator overloading so that it works with free functions via UFCS instead of requiring that it be part of the type. It's a terrible idea IMHO to allow random code to add an overloaded operator to a type rather having it actually be part of the type's design, and in addition to that, it doesn't play at all nicely with symbol conflicts, because you're using an operator rather than a function, meaning that not only do you have no way to specify which version of the overloaded operator code should use, but it would completely defeat the purpose of using an overloaded operator in the first place even if you could. But fortunately, Walter agrees with me (or at least did, the last time the subject came up in the newsgroup), so I don't think that I have to worry about overloaded operators be definable via free functions.

- Jonathan M Davis