Feature request: Path append operators for strings
monarchdodra at gmail.com
Wed Jul 3 06:24:40 PDT 2013
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.
> 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
int a = 1;
int b = 2;
(*a.ptr).ptr[0 .. 16] += (*b.ptr).ptr[0 .. 16];
Yeah... not optimal :/ This also discards static type information.
More information about the Digitalmars-d