On Wednesday, July 03, 2013 00:55:59 TommiT wrote:
> So no wonder I was under the impression that we're allowed to overload the meaning of operators.

Well, of course, you _can_ overload them to do different stuff. It's trivial to make most overloaded operators do something completely different from what they do normally. The argument against it is that doing so is bad practice, because it makes your code hard to understand. And for some operators (e.g. opCmp and opEquals), D actually implements the overloaded operator in a way that giving it an alternate meaning doesn't work. You _could_ do it with / though. It's just arguably bad practice to do so. But since you can get the same functonality out of a normal function without the confusion, it really doesn't make sense in general to overload operators to do something fundamentally different with a user-defined type than what they do with the built-in types. However, some people are really hung up on making everything terse or making it look like mathh or whatnot and insist on abusing operators by overloading them with completely different meanings.

- Jonathan M Davis

On 07/02/13 22:47, TommiT wrote:
>  Division operator for strings doesn't make any sense, and I doubt there will ever be some other meaning for '/' that would make more sense than "a directory separator" for strings in the context of programming.

Umm,

> $ /usr/bin/pike
> Pike v7.8 release 537 running Hilfe v3.5 (Incremental Pike Frontend)
> > "/a/b//c" / "/";
> (1) Result: ({ /* 5 elements */
>                 "",
>                 "a",
>                 "b",
>                 "",
>                 "c"
>             })

That's the only sane use of the division operator on string types; anything else would be extremely confusing.

And this still does not mean that it would be a good idea in D. Typing out "splitter()" is not /that/ hard.

artur

On Tuesday, 2 July 2013 at 22:56:00 UTC, TommiT wrote:
> On Tuesday, 2 July 2013 at 22:28:24 UTC, TommiT wrote:
>>
>> I've never thought of it like that. [..]
>
> Boost Filesystem overloads the meaning of / to mean "append to path". Boost Exception overloads << to mean "add this info to this exception". Boost Serialization overloads << and >> to mean serialize and deserialize, and & to mean either one of those.
>
> So no wonder I was under the impression that we're allowed to overload the meaning of operators.

Such overloads make for code that's fast to write but hard to read, especially to outsiders. It's a tempting direction, but not a good one.

On Tuesday, 2 July 2013 at 21:48:54 UTC, Walter Bright wrote:
> On 7/2/2013 1:47 PM, TommiT wrote:
>> Division operator for strings doesn't make any sense,
>
> That's why overloading / to do something completely unrelated to division is anti-ethical to writing understandable code.

s/division/"The common agreed upon semantic"/

> The classic example of this is the overloading of << and >> for stream operations in C++.

Or overloading ~ to mean "concat" ?

On 7/2/2013 4:28 PM, monarch_dodra wrote:
>> The classic example of this is the overloading of << and >> for stream
>> operations in C++.
>
> Or overloading ~ to mean "concat" ?

Binary ~ has no other meaning, so it is not "overloading" it to mean something else.

On Tuesday, 2 July 2013 at 23:08:37 UTC, Artur Skawina wrote:
> On 07/02/13 22:47, TommiT wrote:
>>  Division operator for strings doesn't make any sense, and I doubt there will ever be some other meaning for '/' that would make more sense than "a directory separator" for strings in the context of programming.
>
> Umm,
>
>> $ /usr/bin/pike
>> Pike v7.8 release 537 running Hilfe v3.5 (Incremental Pike Frontend)
>> > "/a/b//c" / "/";
>> (1) Result: ({ /* 5 elements */
>>                 "",
>>                 "a",
>>                 "b",
>>                 "",
>>                 "c"
>>             })
>
> That's the only sane use of the division operator on string types;
> anything else would be extremely confusing.
>
> And this still does not mean that it would be a good idea in D.
> Typing out "splitter()" is not /that/ hard.
>
> artur

Perhaps an even more logical meaning for / operator for strings would be to divide the string to N equal sized parts (plus a potential remainder):
"abcdefg" / 3
result: ["ab", "cd", "ef", "g"]

But your "divide this string using this divider character" is pretty logical too (once you know it).

On Tuesday, 2 July 2013 at 22:28:24 UTC, TommiT wrote:
> On Tuesday, 2 July 2013 at 21:48:54 UTC, Walter Bright wrote:
>> On 7/2/2013 1:47 PM, TommiT wrote:
>>> Division operator for strings doesn't make any sense,
>>
>> That's why overloading / to do something completely unrelated to division is anti-ethical to writing understandable code. The classic example of this is the overloading of << and >> for stream operations in C++.
>
> I've never thought of it like that. At some point I remember writing a vector type which overloaded its binary * operator to mean dot product (or cross product, I can't remember). So, you can overload an operator, but you can't overload the meaning of an operator.

This is something I was discussing with a friend recently, and we agreed it would be cool if there were set of operators with no definition until overloaded, so you could use e.g. (.) for dot product, (*) for cross product, (+) (or maybe [+]?) for matrix add, etc. instead of overloading things that already have specific, well-understood meaning.

-Wyatt

On Wednesday, 3 July 2013 at 12:24:33 UTC, Wyatt wrote:
> On Tuesday, 2 July 2013 at 22:28:24 UTC, TommiT wrote:
>> On Tuesday, 2 July 2013 at 21:48:54 UTC, Walter Bright wrote:
>>> On 7/2/2013 1:47 PM, TommiT wrote:
>>>> Division operator for strings doesn't make any sense,
>>>
>>> That's why overloading / to do something completely unrelated to division is anti-ethical to writing understandable code. The classic example of this is the overloading of << and >> for stream operations in C++.
>>
>> I've never thought of it like that. At some point I remember writing a vector type which overloaded its binary * operator to mean dot product (or cross product, I can't remember). So, you can overload an operator, but you can't overload the meaning of an operator.
>
> This is something I was discussing with a friend recently, and we agreed it would be cool if there were set of operators with no definition until overloaded, so you could use e.g. (.) for dot product, (*) for cross product, (+) (or maybe [+]?) for matrix add, etc. instead of overloading things that already have specific, well-understood meaning.
>
> -Wyatt

I don't see why we couldn't add the actual unicode ∙ and × characters to the language, make them operators and give them the fixed meaning of dot product and cross product respectively.

Wouldn't + be the correct operator to use for matrix addition. What happens when matrices are added is quite different from when real values are added, but the meaning of + is still addition for the both of them.

On Wednesday, 3 July 2013 at 12:45:53 UTC, TommiT wrote:
> I don't see why we couldn't add the actual unicode ∙ and × characters to the language, make them operators and give them the fixed meaning of dot product and cross product respectively.
>
> Wouldn't + be the correct operator to use for matrix addition. What happens when matrices are added is quite different from when real values are added, but the meaning of + is still addition for the both of them.

That's also a possibility, I suppose, but the real thrust is it would allow you to have very clear (as in, visually offset by some sort of brace, in this example) operators that handle whatever weird transform you want for any convoluted data structure you care to define one for.

That they can be entered with a standard 104-key keyboard without groping about for however people prefer to enter unicode characters is just icing.

-Wyatt

On Wednesday, 3 July 2013 at 12:45:53 UTC, TommiT wrote:
> On Wednesday, 3 July 2013 at 12:24:33 UTC, Wyatt wrote:
>> On Tuesday, 2 July 2013 at 22:28:24 UTC, TommiT wrote:
>>> On Tuesday, 2 July 2013 at 21:48:54 UTC, Walter Bright wrote:
>>>> On 7/2/2013 1:47 PM, TommiT wrote:
>>>>> Division operator for strings doesn't make any sense,
>>>>
>>>> That's why overloading / to do something completely unrelated to division is anti-ethical to writing understandable code. The classic example of this is the overloading of << and >> for stream operations in C++.
>>>
>>> I've never thought of it like that. At some point I remember writing a vector type which overloaded its binary * operator to mean dot product (or cross product, I can't remember). So, you can overload an operator, but you can't overload the meaning of an operator.
>>
>> This is something I was discussing with a friend recently, and we agreed it would be cool if there were set of operators with no definition until overloaded, so you could use e.g. (.) for dot product, (*) for cross product, (+) (or maybe [+]?) for matrix add, etc. instead of overloading things that already have specific, well-understood meaning.
>>
>> -Wyatt
>
> I don't see why we couldn't add the actual unicode ∙ and × characters to the language, make them operators and give them the fixed meaning of dot product and cross product respectively.
>
> Wouldn't + be the correct operator to use for matrix addition. What happens when matrices are added is quite different from when real values are added, but the meaning of + is still addition for the both of them.

Technically, + is already 1D matrix addition (or should I say +=). You can toy around to make it work for N-Dimensional matrixes:

--------
import std.stdio;

void main()
{
    int[4][4] a = 1;
    int[4][4] b = 2;
    (*a.ptr).ptr[0 .. 16] += (*b.ptr).ptr[0 .. 16];
    writeln(a);
}
--------

Yeah... not optimal :/ This also discards static type information.