Frank Benoit Wrote:

> String concatenation in Java:
> 
> "abc " + a + " bla";
> 
> where a is an interface ref.
> 
> Ported to D, this look like this:
> 
> "abc " ~ (cast(Object)a).toString ~ " bla";
> 
> This are 3 steps more:
> 1.) explicit cast to Object (interface/class compatibility!)
> 2.) explicit call to toString
> 3.) put additional parentheses
> 
> I would be happy if we could remove all three of this annoying points.

so interfaces are not Objects. actually they have no common ancestor. that's pretty much fuckshat-up. damn.

superdan wrote:
> Ary Borenszweig Wrote:
> 
>> Frank Benoit a écrit :
>>> String concatenation in Java:
>>>
>>> "abc " + a + " bla";
>>>
>>> where a is an interface ref.
>>>
>>> Ported to D, this look like this:
>>>
>>> "abc " ~ (cast(Object)a).toString ~ " bla";
>>>
>>> This are 3 steps more:
>>> 1.) explicit cast to Object (interface/class compatibility!)
>>> 2.) explicit call to toString
>>> 3.) put additional parentheses
>>>
>>> I would be happy if we could remove all three of this annoying points.
>> Exactly the same thought here. Also:
>>
>> int i = ...;
>> char[] x = "You pressed button " + i;
>>
>> Oops... doesn't compile. To fix it:
>>
>> import std.string;
>>
>> int i = ...;
>> char[] x = "You pressed button " + toString(i);
>>
>> But wait, if that piece of code is inside a method of a class, than (WHY?) it thinks it's the toString() method, so you end up writing:
>>
>> import std.string;
>>
>> int i = ...;
>> char[] x = "You pressed button " + std.string.toString(i);
>>
>> Those are the cases I find D not nice.
> 
> yarp i concur. phobos oughtta have a function asStr that converts everything to string and concats. then you write:
> 
> auto x = asStr("You pressed button ", i, " with your pinky toe");
> 

This is also known as std.string.format.

downs a écrit :
> superdan wrote:
>> Ary Borenszweig Wrote:
>>
>>> Frank Benoit a écrit :
>>>> String concatenation in Java:
>>>>
>>>> "abc " + a + " bla";
>>>>
>>>> where a is an interface ref.
>>>>
>>>> Ported to D, this look like this:
>>>>
>>>> "abc " ~ (cast(Object)a).toString ~ " bla";
>>>>
>>>> This are 3 steps more:
>>>> 1.) explicit cast to Object (interface/class compatibility!)
>>>> 2.) explicit call to toString
>>>> 3.) put additional parentheses
>>>>
>>>> I would be happy if we could remove all three of this annoying points.
>>> Exactly the same thought here. Also:
>>>
>>> int i = ...;
>>> char[] x = "You pressed button " + i;
>>>
>>> Oops... doesn't compile. To fix it:
>>>
>>> import std.string;
>>>
>>> int i = ...;
>>> char[] x = "You pressed button " + toString(i);
>>>
>>> But wait, if that piece of code is inside a method of a class, than (WHY?) it thinks it's the toString() method, so you end up writing:
>>>
>>> import std.string;
>>>
>>> int i = ...;
>>> char[] x = "You pressed button " + std.string.toString(i);
>>>
>>> Those are the cases I find D not nice.
>> yarp i concur. phobos oughtta have a function asStr that converts everything to string and concats. then you write:
>>
>> auto x = asStr("You pressed button ", i, " with your pinky toe");
>>
> 
> This is also known as std.string.format.

But concatenating such things is so common... Instead of doing what it is obvious, you get an error. At least built-in types should have opCat and opCat_r defined like that.

downs Wrote:

> superdan wrote:
> > Ary Borenszweig Wrote:
> > 
> >> Frank Benoit a écrit :
> >>> String concatenation in Java:
> >>>
> >>> "abc " + a + " bla";
> >>>
> >>> where a is an interface ref.
> >>>
> >>> Ported to D, this look like this:
> >>>
> >>> "abc " ~ (cast(Object)a).toString ~ " bla";
> >>>
> >>> This are 3 steps more:
> >>> 1.) explicit cast to Object (interface/class compatibility!)
> >>> 2.) explicit call to toString
> >>> 3.) put additional parentheses
> >>>
> >>> I would be happy if we could remove all three of this annoying points.
> >> Exactly the same thought here. Also:
> >>
> >> int i = ...;
> >> char[] x = "You pressed button " + i;
> >>
> >> Oops... doesn't compile. To fix it:
> >>
> >> import std.string;
> >>
> >> int i = ...;
> >> char[] x = "You pressed button " + toString(i);
> >>
> >> But wait, if that piece of code is inside a method of a class, than (WHY?) it thinks it's the toString() method, so you end up writing:
> >>
> >> import std.string;
> >>
> >> int i = ...;
> >> char[] x = "You pressed button " + std.string.toString(i);
> >>
> >> Those are the cases I find D not nice.
> > 
> > yarp i concur. phobos oughtta have a function asStr that converts everything to string and concats. then you write:
> > 
> > auto x = asStr("You pressed button ", i, " with your pinky toe");
> > 
> 
> This is also known as std.string.format.

narp that interprets %s and shit which can quickly become dangerous. you'd have to say

auto x = format("", ........);

i also agree with ary that infix could help a ton. but then it would confuse noobs. can't please everyone. life's a bitch.

"Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:g4rhq1$1i7a$1@digitalmars.com...

> But concatenating such things is so common... Instead of doing what it is obvious, you get an error. At least built-in types should have opCat and opCat_r defined like that.

Common in many languages, yes.  Convenient, yes.  But it's a pointless hole in the type system that I don't want to see opened.  Having used D for a while, I've come to appreciate using a function to do formatting rather than string concatenation.  It's more flexible and can be more efficient, and doesn't take that much more typing.

Jarrett Billingsley a écrit :
> "Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:g4rhq1$1i7a$1@digitalmars.com...
> 
>> But concatenating such things is so common... Instead of doing what it is obvious, you get an error. At least built-in types should have opCat and opCat_r defined like that.
> 
> Common in many languages, yes.  Convenient, yes.  But it's a pointless hole in the type system that I don't want to see opened.  Having used D for a while, I've come to appreciate using a function to do formatting rather than string concatenation.  It's more flexible and can be more efficient, and doesn't take that much more typing. 

How is it a pointless hole in the type system? I thought having "~" be the concatenation operator instead of "+" was just to prevent that hole.

"Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:g4rsi1$2cnt$1@digitalmars.com...
>
> How is it a pointless hole in the type system? I thought having "~" be the concatenation operator instead of "+" was just to prevent that hole.

It's a bunch of special cases and a weakening of the type system in one area for no benefit that I can see short of a few saved keystrokes.  The semantics of the concatenation operator would have to be changed for string types (char[], wchar[], dchar[] -- and any permutation of const and invariant of those in D2), but not for any other array types, which is ugly. It also unnecessarily complicates the semantics and lookup rules for opCat, opCat_r, and opCatAssign for user-defined types.

From an entirely cosmetic standpoint, I have a clear preference for:

format("x is {}, y is {}, z is {}", x, y, z)

vs.

"x is " ~ x ~ ", y is " ~ y ~ ", z is " ~ z

Concatenation also tends to make (unexperienced) people do stupid things like

writeln("x is " ~ x);

which creates a completely unnecessary string temporary, but they think that that's the only way to output a number.

I really cannot see any benefit from allowing concatenation of strings and non-strings (and non-characters).

Frank Benoit wrote:

> "abc " + a + " bla";
[...]
> I would be happy if we could remove all three of this annoying points.

This seems as you want to give up strong typing.

The next one may come up with

  x= 2 + a + 4;

where a is an interface and requires that a should be easily transformable for not geetting any error.

Would you allow or forbid that?


-manfred

Manfred_Nowak schrieb:
> Frank Benoit wrote:
> 
>> "abc " + a + " bla";
> [...]
>> I would be happy if we could remove all three of this annoying
>> points. 
> 
> This seems as you want to give up strong typing.
> 
> The next one may come up with
> 
>   x= 2 + a + 4;
> 
> where a is an interface and requires that a should be easily transformable for not geetting any error.
> 
> Would you allow or forbid that?
> 
> 
> -manfred

No, i don't want to give up strong typing.
Primarily i wanted to show that class/interface incompatibility is bad IMHO.

So i would say, 1.) is an important issue, 3.) is annoying and 2.) would be nice syntax sugar.

Frank Benoit wrote:

> So i would say, 1.) is an important issue

I agree with the importance.

But my first thought was, that even explicit conversion of an interface to an `Object' should not enrich the functionality of the object referenced through the interface.

This contradicts your wishes. But because at present I have no arguments supporting my first thought, please handle my post as a remark only.

-manfred