July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 7/5/2013 9:17 AM, H. S. Teoh wrote:
> Python uses +.
There's much historical precedence for + meaning concatenation, and much historical experience with the resulting ambiguity. The famous example is:
"123" + 4
? In D, the canonical problem is:
int[] array;
array + 4
Does that mean append 4 to array, or add 4 to each element of array? What if you want to create a user defined type that supports both addition and concatenation?
Use + for addition, ~ for concatenation, and all these problems go away.
|
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to TommiT | On Friday, 5 July 2013 at 14:59:39 UTC, TommiT wrote: > It's rather C++'s std::string which overloads the meaning of + to mean "concatenation". I wonder if some other programming language has assigned some other symbol (than ~) to mean "concatenation". I guess math uses || for it. || is used for a different kind of concatenation [1] For strings, math uses middle dot, (a⋅b) or even just (ab) like with multiplication [2] [1]: https://en.wikipedia.org/wiki/Concatenation_(mathematics) [2]: https://en.wikipedia.org/wiki/String_operations#Strings_and_languages |
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Fri, Jul 05, 2013 at 10:44:43AM -0700, Walter Bright wrote: > On 7/5/2013 9:17 AM, H. S. Teoh wrote: > >Python uses +. > > There's much historical precedence for + meaning concatenation, and much historical experience with the resulting ambiguity. Which leads to some nasty situations in Javascript, where sometimes what you think is an int, is actually a string, and you wonder why your calculation is producing strange results. Or vice versa, when you're trying to concatenate strings, and get a strange large number instead. > The famous example is: > > "123" + 4 > > ? In D, the canonical problem is: > > int[] array; > > array + 4 > > Does that mean append 4 to array, or add 4 to each element of array? What if you want to create a user defined type that supports both addition and concatenation? > > Use + for addition, ~ for concatenation, and all these problems go away. It doesn't necessarily have to be ~, as long as it's something other than + (or any other numerical binary operator). Perl uses '.', but in D's case, that would be a bad idea, since you'd have ambiguity in: auto x = mod1.x . mod2.y; // concatenation or long module path name? It's not a problem in Perl, because Perl uses :: as module separator, like C++. Your example is somewhat faulty, though; adding 4 to each element of the array would have to be written "array[] + 4", wouldn't it? You can't make the [] optional, because if you have an array of arrays, then you're in trouble: int[][] aoa; aoa ~ [1]; // append to outer array, or each inner array? While it's possible to use type-matching to decide, it seems like a bug waiting to happen. Much better if array <op> x always means apply <op> to the entire array, and array[] <op> x to mean apply <op> to each array element. T -- People tell me I'm stubborn, but I refuse to accept it! |
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to TommiT | On Friday, July 05, 2013 16:59:38 TommiT wrote:
> On Tuesday, 2 July 2013 at 23:28:41 UTC, monarch_dodra 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.
> >
> > 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" ?
>
> It's rather C++'s std::string which overloads the meaning of + to mean "concatenation". I wonder if some other programming language has assigned some other symbol (than ~) to mean "concatenation". I guess math uses || for it.
Most languages I've used use + for concatenating strings, so it was definitely surprising to me that D didn't. I have no problem with the fact that it has a specific operator for concatenation (and there are some good reasons for it), but + seems to be pretty standard across languages from what I've seen. I've certainly never seen another language use ~ for that purpose, but at the moment, I can't remember whether I've ever seen another programming language use ~ for _any_ purpose.
- Jonathan M Davis
|
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | > Most languages I've used use + for concatenating strings, so it was definitely
> surprising to me that D didn't. I have no problem with the fact that it has a
> specific operator for concatenation (and there are some good reasons for it),
> but + seems to be pretty standard across languages from what I've seen. I've
> certainly never seen another language use ~ for that purpose, but at the
> moment, I can't remember whether I've ever seen another programming language
> use ~ for _any_ purpose.
>
> - Jonathan M Davis
logical not in e.g. Java?
|
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On 07/05/2013 09:43 PM, Namespace wrote:
>> Most languages I've used use + for concatenating strings, so it was
>> definitely
>> surprising to me that D didn't. I have no problem with the fact that
>> it has a
>> specific operator for concatenation (and there are some good reasons
>> for it),
>> but + seems to be pretty standard across languages from what I've
>> seen. I've
>> certainly never seen another language use ~ for that purpose, but at the
>> moment, I can't remember whether I've ever seen another programming
>> language
>> use ~ for _any_ purpose.
>>
>> - Jonathan M Davis
> logical not in e.g. Java?
Unary ~ is bitwise not in Java and D, and he is referring to binary usage.
|
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | > Unary ~ is bitwise not in Java and D, and he is referring to binary usage. > [...] use ~ for _any_ purpose. I'd expected that *any* really means *any* and do not refer to binary. |
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On Friday, July 05, 2013 22:09:53 Namespace wrote:
> > Unary ~ is bitwise not in Java and D, and he is referring to binary usage.
> >
> > [...] use ~ for _any_ purpose.
>
> I'd expected that *any* really means *any* and do not refer to binary.
I did mean any, not just binary. I thought that there might be a case of it being used as a unary operator somewhere in at least one language I'd used, but I couldn't think of any when I posted (probably due to a combination of just having gotten up and the fact that I use bitwise operations very rarely).
- Jonathan M Davis
|
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On 07/05/2013 10:09 PM, Namespace wrote:
>> Unary ~ is bitwise not in Java and D, and he is referring to binary
>> usage.
>
>> [...] use ~ for _any_ purpose.
> I'd expected that *any* really means *any* and do not refer to binary.
Yes. Neither do 'use', 'for' and 'purpose'. Establishing that it is likely that ~ is referring to binary requires some more context (eg. it is likely that the two usages of ~ in his post refer to the same thing), common sense or the assumption that Jonathan probably knows about the unary usage. (Parsing natural language is quite hard though, so I could be wrong.)
|
July 05, 2013 Re: Feature request: Path append operators for strings | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 07/05/2013 10:34 PM, Timon Gehr wrote:
> On 07/05/2013 10:09 PM, Namespace wrote:
>>> Unary ~ is bitwise not in Java and D, and he is referring to binary
>>> usage.
>>
>>> [...] use ~ for _any_ purpose.
>> I'd expected that *any* really means *any* and do not refer to binary.
>
> Yes. Neither do 'use', 'for' and 'purpose'. Establishing that it is
> likely that ~ is referring to binary requires some more context (eg. it
> is likely that the two usages of ~ in his post refer to the same thing),
> common sense or the assumption that Jonathan probably knows about the
> unary usage. (Parsing natural language is quite hard though, so I could
> be wrong.)
>
Turns out I was wrong. :o)
|
Copyright © 1999-2021 by the D Language Foundation