On Fri, 2016-09-30 at 23:31 +0000, Sai via Digitalmars-d wrote:

> Genuine question: In the post Java languages, how many languages allowed unrestricted operator overloading and did that cause any similar mess?

It is not feasible to provide a count, as there is always another language one forgot.

Groovy, Kotlin, Ceylon, and Scala certainly allow operator overloading. Scala even allows new operator symbol definition. There are some incomprehensible Scala programs because of this. But then there are many incomprehensible D programs – you can play code golf in any language. Just because there is a feature in a language doesn't mean it has to be abused.

I cannot remember offhand whether Fantom, Golo, Gosu, etc. allow operator overloading.

The core lesson of Python is that if you allow everything to happen, there can still be a base of excellent code. Paternalism/maternalism in programming languages is massively overrated. Youngsters will escape the constraints. In the case of D operator overloading restrictions to the glories (!) that is C++.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright wrote:
> On 9/28/2016 6:58 AM, Timon Gehr wrote:
>>> An excellent example of that is the std.regex package.
>> It's actually a bad example, because it is irrelevant: it is obviously a bad
>> idea to implement regex using operator overloading, because the regex operators
>> have no D equivalent.
>
> Yet this "obviously bad" idea regularly resurfaces as a cool use of expression templates and respected people in the industry like it and advocate it.
>
>
>> Assume I have two symbolic expressions a and b:
>>
>> Expression a=variable("a"), b=variable("b");
>>
>> Why should I be allowed to do
>>
>> auto c = a + b; // symbolic value a + b
>>
>> but not
>>
>> auto d = a <= b; // symbolic value a <= b
>
> Because there is no way to stop the former but still have operator overloading.

The fact that it's not possible to overload < but have to use the ternary opCmp is even a performance problem. All std algorithms only use less as a predicate, leading to lots of unnecessary cycles when e.g. sorting UDTs.

While I agree with your point on expression templates, overloading comparison operators has valid use cases.

On 10/1/16 3:13 AM, Martin Nowak wrote:
> The fact that it's not possible to overload < but have to use the
> ternary opCmp is even a performance problem. All std algorithms only use
> less as a predicate, leading to lots of unnecessary cycles when e.g.
> sorting UDTs.

I've also been often annoyed by having to write

return a < b ? -1 : a > b;

in e.g. checkedint. Does inlining take care of this? -- Andrei

On 10/1/16 7:33 AM, Andrei Alexandrescu wrote:
> On 10/1/16 3:13 AM, Martin Nowak wrote:
>> The fact that it's not possible to overload < but have to use the
>> ternary opCmp is even a performance problem. All std algorithms only use
>> less as a predicate, leading to lots of unnecessary cycles when e.g.
>> sorting UDTs.
>
> I've also been often annoyed by having to write
>
> return a < b ? -1 : a > b;
>
> in e.g. checkedint. Does inlining take care of this? -- Andrei

Apparently in dmd the generated code is less efficient: https://goo.gl/OWxbA0. In gdc it's the same: https://godbolt.org/g/NmUyXM. I couldn't test with ldc, http://ldc.acomirei.ru seems down. -- Andrei

On Saturday, 1 October 2016 at 07:13:39 UTC, Martin Nowak wrote:
> The fact that it's not possible to overload < but have to use the ternary opCmp is even a performance problem. All std algorithms only use less as a predicate, leading to lots of unnecessary cycles when e.g. sorting UDTs.

On Saturday, 1 October 2016 at 11:53:07 UTC, Andrei Alexandrescu wrote:
> Apparently in dmd the generated code is less efficient: https://goo.gl/OWxbA0. In gdc it's the same: https://godbolt.org/g/NmUyXM. I couldn't test with ldc, http://ldc.acomirei.ru seems down. -- Andrei

On Saturday, 1 October 2016 at 06:46:31 UTC, Russel Winder wrote:
> This debate is about whether D constrains people as Java does or whether it enables people as C++ and Python do.
>
> Or use C++ or Python which allow for this. Fine, end of D having a future amongst a large section of the programming population. This is fine. Unless D wants to be a player in this game.
>
> This has already been done, read the thread. SQLAlchemy. The expression language is a a lovely builder DSL for constructing SQL entirely in Python with no parser overhead. No operator overloading, no DSL for builder languages. See same on the JVM: in Java you can't do it, Kotlin, Ceylon, Scala, Groovy, do it beautifully, and a lot of people do.

This isn't a PR yet because it's not nearly ready for general consumption, but these are all good points and I'd greatly appreciate if you would all please take a few minutes to express them in the DIP and get the changes merged so that we can have something that lays out clearly the pros and cons of this change.

https://github.com/pineapplemachine/DIPs/blob/operator_overload_expansion/DIPs/DIP1003.md

On Fri, 30 Sep 2016 23:31:19 +0000, Sai wrote:
> Genuine question: In the post Java languages, how many languages allowed unrestricted operator overloading and did that cause any similar mess?

Groovy doesn't allow you to overload comparison operators individually, and probably most JVM languages likewise. This is to retain compatibility with Java, which has `.compareTo()` instead of `isLessThan()` etc.

Ruby allows you to override individual comparison operators, with a special operator `<=>` for combined comparisons. Nim lets you overload arbitrary operators and create your own; some old discussions suggest that the Comparable type is based on `<` alone.

On Fri, 30 Sep 2016 19:33:33 +0000, pineapple wrote:
> How many people have to state it how many times in how many different ways before it gets through? These are stupid goals. They reflect intention that has no basis in reason, that has no basis in reality, that is a blindly-enforced dogma.

More like: this is the common use case, so let's try to make that as smooth as possible, both for implementors and readers. And mucking about in the same area can add wrinkles that confuse people.

The takeaway should be that we should exercise caution, not that we should refuse to change the language. But the basic idea does make sense.

I'm not sure it's straightforward to make other operators consistent in the same way. You could try to enforce things like: typeof(a OP b) should be co/contravariant with typeof(a) or typeof(b) for math operators; opApply and opIndex should deal with the same types (though it's valid to add extras); that kind of thing. It does seem inconsistent that no attempt was made, but the language was only Walter Bright for nearly a decade, and one person doesn't have that much time.

With most of the language and compiler work still being Walter Bright, he has much more say in the direction of the language than anyone else.

> It always would have been simpler if, in the first place, opBinary had caught comparison operators and opCmp and opEquals were omitted. Instead, those making the decisions went out of their way to impose these arbitrary limitations. If we can start now to untangle that mistake, it will make D more tenable for real-world code.

That would have been tricky, or at least unpleasant, before auto return types. Auto return types were introduced after 2010, and opCmp was introduced before 2006.

On Friday, 30 September 2016 at 22:38:07 UTC, Walter Bright wrote:
> On 9/30/2016 1:14 PM, Minty Fresh wrote:
>> Metathesiophobia
>
> Repeatedly suggesting people who don't agree with you have mental disorders does not advance your case and is not appreciated here.

Metathesiophobia is not a mental disorder, it's a phobia. There's quite a bit of distinction there.
Specifically it's an ungrounded fear or dislike of change. It's altogether not uncommon, actually.

> A more productive way forward is for you (and those who agree with you) to prepare a formal DIP and submit it. It's the way significant language change proposals are done.

That was sort of the initial intent of this thread. To test the waters and see if the idea would have support.
But it seems the community is extremely torn on the matter.

On Friday, 30 September 2016 at 23:31:19 UTC, Sai wrote:
> Genuine question: In the post Java languages, how many languages allowed unrestricted operator overloading and did that cause any similar mess?
>
> Thanks in advance for any answers.

Although there maybe a bit of bias here, but I'd say Rub does it quite well (although the syntax for unary operator overloads is a bit bizarre), since I work with the language on a daily basis.

But going a step further there's languages like Haskell that allow defining completely new operators.

Both of the aforementioned have amassed an exceedingly large following at this point.

On Sat, 2016-10-01 at 14:55 +0000, Chris Wright via Digitalmars-d wrote:

> Groovy doesn't allow you to overload comparison operators
> individually,
> and probably most JVM languages likewise. This is to retain
> compatibility
> with Java, which has `.compareTo()` instead of `isLessThan()` etc.

Yes it does.  http://groovy-lang.org/operators.html

There is *also* compareTo.

> Ruby allows you to override individual comparison operators, with a
> special operator `<=>` for combined comparisons. Nim lets you
> overload
> arbitrary operators and create your own; some old discussions
> suggest
> that the Comparable type is based on `<` alone.

Groovy also supports the spaceship operator.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder