On 09/30/2016 03:18 PM, Timon Gehr wrote:
> On 30.09.2016 21:02, Timon Gehr wrote:
>> On 30.09.2016 03:15, Chris Wright wrote:
>>> ...
>>
>>> Wouldn't that be fun?
>>>
>>
>> Certainly.
>
> On a related note:
>
> alias Seq(T...)=T;
>
> struct S{
>     int x;
>     S opBinary(string op:"+",T...)(T args){
>         S r=this;
>         foreach(a;args) r.x+=a;
>         return r;
>     }
> }
>
> void main(){
>     import std.stdio;
>     assert(S(1) + Seq!(2,3,4) == S(10));
> }

That looks awfully cool! -- Andrei

On Friday, 30 September 2016 at 09:55:36 UTC, pineapple wrote:
> On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis wrote:
>> Except that it kind of is. It's an example of a language allowing you to mess with too much and make it so that it doesn't function as expected, which is what happens when you overload operators to act in a way inconsistent with how they work with the built-in types.
>
> Let me see if I understand your argument: We can't make D more expressive because a language far more popular than D is so expressive it makes it possible to do unconventional things, if you are so inclined?
But operator overloading doesn't increase the language expressiveness.
They provide nothing that you can't already do using ordinary function calls.
So forget expressiveness as an argument.
Operator overload is syntactic sugar, added to serve a single purpose: to allow mimic buildin types. So they should provide everything needed to do so, and nothing more. Adding more may be asked for, but this is not reasonable, because it is unrelated to the original purpose but increases only the possibilities to obfuscate the code by doing something misleading (there are already endless such possibilities, but that makes asking for more no more reasonable).

On Friday, 30 September 2016 at 19:09:25 UTC, Timon Gehr wrote:
> On 30.09.2016 18:11, Jonathan M Davis via Digitalmars-d wrote:
>> Regardless, D already has a lot of powerful stuff in it, much of which will
>> allow you to blow your foot off if you're really inclined to. The overloaded
>> operators just so happened to be implemented in a way that doesn't let you
>> blow your feet off as freely as C++'s overloaded operators will let you do.
>
>
> OTOH, feet are useless if you are not allowed to walk (even if you choose not to blow them off).
You are allowed to walk. You can express everything that is possible with operator overloading in lots of other ways. And you can express everything that operator overloading was designed for with it - but maybe not everything beyond that. Use other ways to express such. If the compactness of expression written using operators is everything you are interested in - define some language and write a parser for it, and enjoy how short you can express everything you need with it.
You can even write such stuff directly in your D code and let some string mixins massage it to compile.

I can't see the point to relax the rules for operator overloading unless you can show that they prevent parts of the original design goal.

PS: opCmp can return float, so the comparison can result in NaN (not conparable) - and as this is necessary to mimic some basic types (all floatingpoint types) removing this possibility would indeed prevent parts of the original design goal!

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.

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.

On 30.09.2016 22:14, Andrei Alexandrescu wrote:
> On 09/30/2016 03:18 PM, Timon Gehr wrote:
>> On 30.09.2016 21:02, Timon Gehr wrote:
>>> On 30.09.2016 03:15, Chris Wright wrote:
>>>> ...
>>>
>>>> Wouldn't that be fun?
>>>>
>>>
>>> Certainly.
>>
>> On a related note:
>>
>> alias Seq(T...)=T;
>>
>> struct S{
>>     int x;
>>     S opBinary(string op:"+",T...)(T args){
>>         S r=this;
>>         foreach(a;args) r.x+=a;
>>         return r;
>>     }
>> }
>>
>> void main(){
>>     import std.stdio;
>>     assert(S(1) + Seq!(2,3,4) == S(10));
>> }
>
> That looks awfully cool! -- Andrei
>

[my code here]

>    a.isLessThan(b)


I understand the concern of possible mess due to unrestricted use of operator overloading (like C++). Java has clearly driven the point home by banning the operator overloading altogether.

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.

On 30.09.2016 23:43, Dominikus Dittes Scherkl wrote:
> On Friday, 30 September 2016 at 09:55:36 UTC, pineapple wrote:
>> On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis wrote:
>>> Except that it kind of is. It's an example of a language allowing you
>>> to mess with too much and make it so that it doesn't function as
>>> expected, which is what happens when you overload operators to act in
>>> a way inconsistent with how they work with the built-in types.

Please don't do this; it destroys threading.

>
> On Friday, 30 September 2016 at 19:09:25 UTC, Timon Gehr wrote:
>> On 30.09.2016 18:11, Jonathan M Davis via Digitalmars-d wrote:
>>> Regardless, D already has a lot of powerful stuff in it, much of
>>> which will
>>> allow you to blow your foot off if you're really inclined to. The
>>> overloaded
>>> operators just so happened to be implemented in a way that doesn't
>>> let you
>>> blow your feet off as freely as C++'s overloaded operators will let
>>> you do.
>>
>>
>> OTOH, feet are useless if you are not allowed to walk (even if you
>> choose not to blow them off).
> You are allowed to walk.

There's a continuum here. Another data point:
https://www.youtube.com/watch?v=IqhlQfXUk7w

(Though here, one seems to require a good set of feet.)

> You can express everything that is possible
> with operator overloading in lots of other ways.

Everybody knows this. And everyone in the above video is getting where they are going.

> And you can express
> everything that operator overloading was designed for with it

Hopefully. My qualm is with the design. (It is not that significant, it's basically in the "fly that sits on your face at an irregular frequency" corner.)

> - but
> maybe not everything beyond that. Use other ways to express such. If the
> compactness of expression written using operators is everything you are
> interested in

Am not. You might be confusing me with someone else. But don't assume I'm going to accept huge overhead, because this does destroy the point of the original exercise at some point.

> - define some language

Yes, I can design my own programming language. However, I don't currently have the resources to create the perfect tool for every job I face.

> and write a parser for it,

Sure, I also have a parser. Now what? It does not integrate nicely with D code.

> and enjoy how short you can express everything you need with it.

Conciseness never hurts. I'm interested in using notation that is similar to the one I use on paper and in scientific publications. It's also about ensuring correctness by making it easy to understand at a glance what is written down (by e.g. a domain expert). This is understood to have certain limitations (e.g. there's no built-in integral operator), but the notation that does exist corresponds precisely -- there is no misusing of names anywhere.


> You can even write such stuff directly in your D code and let some
> string mixins massage it to compile.
> ...

This does not scale. (It works for some things, not others.)

> I can't see the point to relax the rules for operator overloading unless
> you can show that they prevent parts of the original design goal.
> ...

Then I'm not interested in trying to convince you because you can always just claim that the use case I present was not part of the original design goal (which is not written down formally anywhere).

> PS: opCmp can return float, so the comparison can result in NaN (not
> conparable) - and as this is necessary to mimic some basic types (all
> floatingpoint types) removing this possibility would indeed prevent
> parts of the original design goal!

I know. I believe I was even the first one to point this out on the NG. It was an accident, not designed. The cause was lack of some pointless restriction.

On 01.10.2016 01:31, Sai wrote:
>
>
> I understand the concern of possible mess due to unrestricted use of
> operator overloading (like C++).

C++ does it in std.

On Friday, 30 September 2016 at 22:38:07 UTC, Walter Bright wrote:
> 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.

A good idea.

I have written a rough initial draft for this DIP and it currently resides here, in a fork: https://github.com/pineapplemachine/DIPs/blob/operator_overload_expansion/DIPs/DIP1003.md

I invite anyone with an opinion - which I imagine is just about everyone who has participated in this thread - to please contribute to the DIP before it's submitted as a PR and for review.

I ask that arguments for and against listed in the DIP not include anything to the effect of merely "it would offer more flexibility" or "it would offer too much flexibility", as I think several pages of discussion have made clear that those holding either opinion are not likely to be swayed by arguments taking the opposing form.

On Fri, 2016-09-30 at 15:38 -0700, Walter Bright via Digitalmars-d wrote:

> 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.

But is the effort worth it? Will the DIP and PR be assessed? Does it have any chance of success? Is there any chance of this long standing position of D on overloading operators being overturned?

Saying "Go prepare a DIP" is both indicating the right thing to do, but also a mechanism of deflecting the idea from having any chance of success at all.

So does a well prepared DIP have a chance of changing D's operator overloading or not?

-- 
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 Fri, 2016-09-30 at 21:43 +0000, Dominikus Dittes Scherkl via Digitalmars-d wrote:

> But operator overloading doesn't increase the language expressiveness.

Expressiveness is not a metric, there isn't even a partial order, it is
a qualitative thing, thus personal to a great extent. What I consider
expressive and what you consider expressive likely are entirely
unrelated. There can be a shared agreement or a disagreement. What is
not acceptable is to state that one person's opinion is true for all
people

> They provide nothing that you can't already do using ordinary function calls.

Correct.

> So forget expressiveness as an argument.

No.

> Operator overload is syntactic sugar, added to serve a single purpose: to allow mimic buildin types. So they should provide everything needed to do so, and nothing more. Adding more may be asked for, but this is not reasonable, because it is unrelated to the original purpose but increases only the possibilities to obfuscate the code by doing something misleading (there are already endless such possibilities, but that makes asking for more no more reasonable).

All high level languages are syntactic sugar, the one true language is machine code, all else is fluff. It just happens that layers of abstraction and "syntactic sugar" are really rather important to building complex software systems.

Any programming language is in fact a meta-language to enable people to construct new languages. All programs are DSLs for some domain. The question at hand is whether a programming language has the right tools for the job. Operator overloading is one tool in the creation of DSLs. D currently seems to have a very hobbled version of this compared to C++, Python, and a very grandiose scheme compared to Go, Fortran.

This debate is about whether D constrains people as Java does or whether it enables people as C++ and Python do.

> You are allowed to walk. You can express everything that is
> possible with operator overloading in lots of other ways. And you
> can express everything that operator overloading was designed for
> with it - but maybe not everything beyond that. Use other ways to
> express such. If the compactness of expression written using
> operators is everything you are interested in - define some
> language and write a parser for it, and enjoy how short you can
> express everything you need with it.
> You can even write such stuff directly in your D code and let
> some string mixins massage it to compile.

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.

> I can't see the point to relax the rules for operator overloading unless you can show that they prevent parts of the original design goal.

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.

Java only survives as a language for constructing new systems because a very large part of the Java programming community cannot be bothered to learn new stuff that doesn't have Java on the label. Even then many are not sure about this Java 8 thing. Indeed many are not even sure Java 5 was a good thing. Yes there are a lot of people still writing new stuff in Java 1.4.2 because generics, streams, modern programming techniques are new fangled syntactic sugar that is not needed to express the algorithm. I can give lots of anecdotal evidence on this drawn from workshops I have presented.

The question here is whether D wants to include these sorts of things or reject them.

But at the heart of the debate is whether a DIP will be evolved into a change to the D language or whether it will be rejected even before it is put together.

-- 
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