Feature request: Path append operators for strings

[monarch_dodra]

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.