www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - One thing from total happiness!!! -Walter!

reply M <M_member pathlink.com> writes:
I am talking about automatic string conversion. 
Even Java has it!

char []s;
int n;

why not?
s=s~n;

This is one thing that java is far better than D, I must sadly say.

Right now I have a line in my code:
xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ",
"$a="~toString(i1),"$b=
"~toString(ids)));

but why not
xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ", "$a="~i1,"$b=
"ids));

Ok, I have 2 sql vars here, but what I had 10? What a mess would my code be.

I know that automatic conversion might be a bit confusing, but it adds so much
to the readability of code. 

D has done so much to simplify reading and writing of code, why stop now?

So why not?
Jul 10 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"M" <M_member pathlink.com> wrote in message 
news:das2qq$2j5g$1 digitaldaemon.com...

 but why not
 xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ", 
 "$a="~i1,"$b=
 "ids));


Using a variadic function instead, and using format(), you could write it as

xchange(xmysql("UPDATE ",table," SET id2 = $a where id = $b ", 
"$a=",i1,"$b="ids));

Not quite the same, but better.


 I know that automatic conversion might be a bit confusing, but it adds so 
 much
 to the readability of code.


That's mainly the reason.  The only "way" to do such a thing currently would 
be to have a String class, with overloaded opCat/opCatAssign operators for 
whatever types you wish to be automatically converted to strings.  Walter 
does _not_ really like implicit operations (like implicit casts, which is 
kind of what this is).
Jul 10 2005
parent M <M_member pathlink.com> writes:
Using a variadic function instead, and using format(), you could write it as

xchange(xmysql("UPDATE ",table," SET id2 = $a where id = $b ", 
"$a=",i1,"$b="ids));


Well, it's not the same sadly.

I thinks I haveto write a code converter. It's sad that what Walter could do in
an hour, I will be doing maybe next few month. (Maybe Walter could add a
compiler switch instead. Ah, I am hoping to much.)
My work is very closly related to text handling and conversion is something I
need very often.

The other thing is if D want's to compete with PHP then it needs this
conversion. For me is D a reasonable alterative to PHP when writing web.

Jarnet, thank you for answering me!

In article <das3lh$2k9g$1 digitaldaemon.com>, Jarrett Billingsley says...

"M" <M_member pathlink.com> wrote in message 
news:das2qq$2j5g$1 digitaldaemon.com...

 but why not
 xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ", 
 "$a="~i1,"$b=
 "ids));


Using a variadic function instead, and using format(), you could write it as

xchange(xmysql("UPDATE ",table," SET id2 = $a where id = $b ", 
"$a=",i1,"$b="ids));

Not quite the same, but better.


 I know that automatic conversion might be a bit confusing, but it adds so 
 much
 to the readability of code.


That's mainly the reason.  The only "way" to do such a thing currently would 
be to have a String class, with overloaded opCat/opCatAssign operators for 
whatever types you wish to be automatically converted to strings.  Walter 
does _not_ really like implicit operations (like implicit casts, which is 
kind of what this is).
Jul 10 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"M" <M_member pathlink.com> wrote in message
news:das2qq$2j5g$1 digitaldaemon.com...

 I am talking about automatic string conversion.
 Even Java has it!

 char []s;
 int n;

 why not?
 s=s~n;

 This is one thing that java is far better than D, I must sadly say.


Implicit conversions often make life easier and code simpler. Unfortunately,
they also have a dark side. Too many of them wind up defeating static type
checking, creating onerous and ugly bugs that manifest themselves only at
runtime.

So it's a balancing act. Too few implicit conversions, and code is a pain to
write. Too many, and it's a pain to debug.
Jul 10 2005
next sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi Walter,

I think implicit stringification of types would be one of those things in the
"good" side of the balancing act. Not so the other way around, though. This
mostly because of two things: 

1) "Strings" have pretty much their own operator in D; you only have to watch
out for that one thing. If the programmer does something like:

writef("Value=" ~ someInt);

I think it's pretty safe to assume he knows exactly what he's getting, in all
situations. Whereas the reverse is not true, because all operators come into
play.

int someInt = 42 + someString; // Ah! Watch out.
float someFloat = 3.14 * someString; // Watch out here too.
double someDouble = 6.66 / someString; // And here. Etc...

2) The second reason is that stringification is (or should be) an
exception-safe, error-free and very simple procedure.

// This is safe:
writef(toString(someInt));
// This not so much:
int someInt = toInt(someString);

Here's a simple, orthogonal solution to the problem:

Define a toString property for all types, just like .max. This is needed only
for primitives, since I believe all objects already have it. Then, when implicit
conversion to string is needed, the variable's toString is called. 

Very simple, no surprising results, and no potential errors. toString should in
theory never fail. This would be a _really_ great feature. I currently have tons
of unsightly toString() calls all over the place. Plus there's the whole
toString collision problem with std.date and co.

Thanks,
--AJG.



In article <dasvio$b5g$1 digitaldaemon.com>, Walter says...

"M" <M_member pathlink.com> wrote in message
news:das2qq$2j5g$1 digitaldaemon.com...

 I am talking about automatic string conversion.
 Even Java has it!

 char []s;
 int n;

 why not?
 s=s~n;

 This is one thing that java is far better than D, I must sadly say.


Implicit conversions often make life easier and code simpler. Unfortunately,
they also have a dark side. Too many of them wind up defeating static type
checking, creating onerous and ugly bugs that manifest themselves only at
runtime.

So it's a balancing act. Too few implicit conversions, and code is a pain to
write. Too many, and it's a pain to debug.
Jul 10 2005
parent reply M <M_member pathlink.com> writes:
Hi Walter,
What you think if there where a ~: operator or something other like that

char []a;
int n;
a=a~:n;

or if you wish
a=""~:n;

better than
a=a~toString(n);

a=toString(n);

+ you won't have this toString collation when you write classes.

What you think?

In article <dat2fp$e61$1 digitaldaemon.com>, AJG says...

Hi Walter,

I think implicit stringification of types would be one of those things in the
"good" side of the balancing act. Not so the other way around, though. This
mostly because of two things: 

1) "Strings" have pretty much their own operator in D; you only have to watch
out for that one thing. If the programmer does something like:

writef("Value=" ~ someInt);

I think it's pretty safe to assume he knows exactly what he's getting, in all
situations. Whereas the reverse is not true, because all operators come into
play.

int someInt = 42 + someString; // Ah! Watch out.
float someFloat = 3.14 * someString; // Watch out here too.
double someDouble = 6.66 / someString; // And here. Etc...

2) The second reason is that stringification is (or should be) an
exception-safe, error-free and very simple procedure.

// This is safe:
writef(toString(someInt));
// This not so much:
int someInt = toInt(someString);

Here's a simple, orthogonal solution to the problem:

Define a toString property for all types, just like .max. This is needed only
for primitives, since I believe all objects already have it. Then, when implicit
conversion to string is needed, the variable's toString is called. 

Very simple, no surprising results, and no potential errors. toString should in
theory never fail. This would be a _really_ great feature. I currently have tons
of unsightly toString() calls all over the place. Plus there's the whole
toString collision problem with std.date and co.

Thanks,
--AJG.



In article <dasvio$b5g$1 digitaldaemon.com>, Walter says...

"M" <M_member pathlink.com> wrote in message
news:das2qq$2j5g$1 digitaldaemon.com...

 I am talking about automatic string conversion.
 Even Java has it!

 char []s;
 int n;

 why not?
 s=s~n;

 This is one thing that java is far better than D, I must sadly say.


Implicit conversions often make life easier and code simpler. Unfortunately,
they also have a dark side. Too many of them wind up defeating static type
checking, creating onerous and ugly bugs that manifest themselves only at
runtime.

So it's a balancing act. Too few implicit conversions, and code is a pain to
write. Too many, and it's a pain to debug.
Jul 11 2005
parent reply M <M_member pathlink.com> writes:
Ok, seriously, what you think of this?

What you think of easy integer to string conversion operator.

Something like ~:

?

In article <datb72$q10$1 digitaldaemon.com>, M says...

Hi Walter,
What you think if there where a ~: operator or something other like that

char []a;
int n;
a=a~:n;

or if you wish
a=""~:n;

better than
a=a~toString(n);

a=toString(n);

+ you won't have this toString collation when you write classes.

What you think?

In article <dat2fp$e61$1 digitaldaemon.com>, AJG says...

Hi Walter,

I think implicit stringification of types would be one of those things in the
"good" side of the balancing act. Not so the other way around, though. This
mostly because of two things: 

1) "Strings" have pretty much their own operator in D; you only have to watch
out for that one thing. If the programmer does something like:

writef("Value=" ~ someInt);

I think it's pretty safe to assume he knows exactly what he's getting, in all
situations. Whereas the reverse is not true, because all operators come into
play.

int someInt = 42 + someString; // Ah! Watch out.
float someFloat = 3.14 * someString; // Watch out here too.
double someDouble = 6.66 / someString; // And here. Etc...

2) The second reason is that stringification is (or should be) an
exception-safe, error-free and very simple procedure.

// This is safe:
writef(toString(someInt));
// This not so much:
int someInt = toInt(someString);

Here's a simple, orthogonal solution to the problem:

Define a toString property for all types, just like .max. This is needed only
for primitives, since I believe all objects already have it. Then, when implicit
conversion to string is needed, the variable's toString is called. 

Very simple, no surprising results, and no potential errors. toString should in
theory never fail. This would be a _really_ great feature. I currently have tons
of unsightly toString() calls all over the place. Plus there's the whole
toString collision problem with std.date and co.

Thanks,
--AJG.



In article <dasvio$b5g$1 digitaldaemon.com>, Walter says...

"M" <M_member pathlink.com> wrote in message
news:das2qq$2j5g$1 digitaldaemon.com...

 I am talking about automatic string conversion.
 Even Java has it!

 char []s;
 int n;

 why not?
 s=s~n;

 This is one thing that java is far better than D, I must sadly say.


Implicit conversions often make life easier and code simpler. Unfortunately,
they also have a dark side. Too many of them wind up defeating static type
checking, creating onerous and ugly bugs that manifest themselves only at
runtime.

So it's a balancing act. Too few implicit conversions, and code is a pain to
write. Too many, and it's a pain to debug.
Jul 12 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
On Tue, 12 Jul 2005 17:26:18 +0200, M <M_member pathlink.com> wrote:


 Ok, seriously, what you think of this?

 What you think of easy integer to string conversion operator.

 Something like ~:

 ?


Ever wrote applications for people that are non-english? Like me (i'm  
german), for example? We write 2/3 this way:

0,666667

Do you see the "," instead of the "."? Converting floating points to  
integers is the same for us. Mathemathics are identical everywhere. But we  
*write* numbers different. And we are not the only ones. En contraire,  
most of the people that program today are not from GB or USA. D has made a  
big step forward in this regard, as its source code is always UTF, not  
some shitty local encoding. Now we're gonna burn that down by specifying  
an operator that does something quite complex?

Nah, i do not think that it's a good idea. There are far more important  
problems than being able to write

str1 = str2 ~: number;

instead of

str1 = str2 ~ toString(number);

Ciao
uwe
Jul 12 2005
parent reply M <M_member pathlink.com> writes:
I am from Estonia, we also write numbers like this.
I mean only integer numbers, no floating point. It is very seldom that I need to
do a floating number to string conversion. But quite often when I need to
convert an integer.

Ps. floating point numbers have more problems like how many digets and so on.

In article <op.sts4rbus6yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...

On Tue, 12 Jul 2005 17:26:18 +0200, M <M_member pathlink.com> wrote:


 Ok, seriously, what you think of this?

 What you think of easy integer to string conversion operator.

 Something like ~:

 ?


Ever wrote applications for people that are non-english? Like me (i'm  
german), for example? We write 2/3 this way:

0,666667

Do you see the "," instead of the "."? Converting floating points to  
integers is the same for us. Mathemathics are identical everywhere. But we  
*write* numbers different. And we are not the only ones. En contraire,  
most of the people that program today are not from GB or USA. D has made a  
big step forward in this regard, as its source code is always UTF, not  
some shitty local encoding. Now we're gonna burn that down by specifying  
an operator that does something quite complex?

Nah, i do not think that it's a good idea. There are far more important  
problems than being able to write

str1 = str2 ~: number;

instead of

str1 = str2 ~ toString(number);

Ciao
uwe
Jul 12 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 I am from Estonia, we also write numbers like this.
 I mean only integer numbers, no floating point. It is very seldom that I  
 need to
 do a floating number to string conversion. But quite often when I need to
 convert an integer.


Still i do not see the benefit. If you like to write things short, do  
something like this:


alias toString toS;

char[] str1;
char[] str2;
int v;

str1 = str2 ~ toS(v);


These are 4 characters more you have to type. How often do you convert  
integers to strings in 100.000 lines of code? How many characters do you  
save? There are a lot of other occasions where a special operator could be  
useful and save some keystrokes. But imagine that there actually were all  
these operators. Your code would be cluttered with things like ?&  or  !:   
or  *~  or  %do  etc. Thus there should be special operators for things  
that happen very often: index access, concatenation, addition, ... but not  
int to string conversion.

Ciao
uwe
Jul 12 2005
next sibling parent reply M <M_member pathlink.com> writes:
Ok, I have toString (or my shorter ver. of it) 372 times in my 9303 line code.
That is one toString in 25 lines. I have 205 'for' (1 in 45) there. 864 'if' (1
in 11). 850 + (pluss) marks (1 in 11).
Ok I have more than twice as much + marks in my code than toString, but integer
to string happens quite often too as you can see. 

So in 100.000 lines of code it would be about 4000 times.

Martin.


In article <op.sttilerv6yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...

 I am from Estonia, we also write numbers like this.
 I mean only integer numbers, no floating point. It is very seldom that I  
 need to
 do a floating number to string conversion. But quite often when I need to
 convert an integer.


Still i do not see the benefit. If you like to write things short, do  
something like this:


alias toString toS;

char[] str1;
char[] str2;
int v;

str1 = str2 ~ toS(v);


These are 4 characters more you have to type. How often do you convert  
integers to strings in 100.000 lines of code? How many characters do you  
save? There are a lot of other occasions where a special operator could be  
useful and save some keystrokes. But imagine that there actually were all  
these operators. Your code would be cluttered with things like ?&  or  !:   
or  *~  or  %do  etc. Thus there should be special operators for things  
that happen very often: index access, concatenation, addition, ... but not  
int to string conversion.

Ciao
uwe
Jul 12 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 Ok, I have toString (or my shorter ver. of it) 372 times in my 9303 line  
 code.


That is quite interesting... :)  What kind of program are you writing?

Ciao
uwe
Jul 12 2005
prev sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi,


Still i do not see the benefit. If you like to write things short, do  
something like this:


alias toString toS;

char[] str1;
char[] str2;
int v;

str1 = str2 ~ toS(v);


These are 4 characters more you have to type. How often do you convert  
integers to strings in 100.000 lines of code? 


I agree that introducing a new operator for only int-to-string conversion is not
a good idea. In fact, I'd say it's a bad idea. We don't need a new operator for
this.

However, consider instead implicit conversion from any type to string. IMHO,
this type of conversion actually happens a _lot_ (or would you disagree?).

I think the right way of handling it is to add .toString properties to
primitives and then make toString be called automatically on conversion. 

This has several advantages:

1) It allows toString to handle some of the internalization issues (via locales,


2) It allows for this very much useful type of construct. In this case,
something like this could really help in debugging:





























Would this not be really useful? And what is the cost, really?
[Not that you said this, but in general]:

1) That you can confuse argument order in function calls?
* That can happen already with or without this feature. This is another issue
entirely (namely, the use named parameters) and it shouldn't masquerade against
string conversion.

2) That operators may not do what is expected?
* There is only _one_ operator to watch for, and that is ~ (fine, two, if you
include ~=). Remember, implicit conversion would only be one-way. From T to
string, not the other way around. Everything else is still the same.

3) That it breaks the statically typed system?
* This is a slippery-slope argument and it doesn't hold water. We are talking
about _one_ very special near-universal case which is strings. I think their use
is common enough that their ease of use and versatility should be made a
priority. 

4) That it hinders overloading?
* Personally, I think it's the opposite. It makes overloading simpler and more
concise. Nevertheless, if you still wanted to overload based on string, it would
still be possible.

Is there a real, compelling reason against calling toString automatically and
making everything have a toString? 

If there is, could someone provide a concrete example of it please?

Thanks,
--AJG.


How many characters do you  
save? There are a lot of other occasions where a special operator could be  
useful and save some keystrokes. But imagine that there actually were all  
these operators. Your code would be cluttered with things like ?&  or  !:   
or  *~  or  %do  etc. Thus there should be special operators for things  
that happen very often: index access, concatenation, addition, ... but not  
int to string conversion.

Ciao
uwe
Jul 12 2005
parent reply Person <Person_member pathlink.com> writes:
Mhm, i see some problems. int fun(int a) int fun(char []d)

fun(5)  which function to call.

Maybe make the conversion impicit for ~ operator

char []h 
int k
u=h~k

And unary ~ would be to convert to string too
like 
char []fun(){
int e;
return ~e;
}

Or is unary ~ already in use?




In article <db1dgr$1ht3$1 digitaldaemon.com>, AJG says...

Hi,


Still i do not see the benefit. If you like to write things short, do  
something like this:


alias toString toS;

char[] str1;
char[] str2;
int v;

str1 = str2 ~ toS(v);


These are 4 characters more you have to type. How often do you convert  
integers to strings in 100.000 lines of code? 


I agree that introducing a new operator for only int-to-string conversion is not
a good idea. In fact, I'd say it's a bad idea. We don't need a new operator for
this.

However, consider instead implicit conversion from any type to string. IMHO,
this type of conversion actually happens a _lot_ (or would you disagree?).

I think the right way of handling it is to add .toString properties to
primitives and then make toString be called automatically on conversion. 

This has several advantages:

1) It allows toString to handle some of the internalization issues (via locales,


2) It allows for this very much useful type of construct. In this case,
something like this could really help in debugging:





























Would this not be really useful? And what is the cost, really?
[Not that you said this, but in general]:

1) That you can confuse argument order in function calls?
* That can happen already with or without this feature. This is another issue
entirely (namely, the use named parameters) and it shouldn't masquerade against
string conversion.

2) That operators may not do what is expected?
* There is only _one_ operator to watch for, and that is ~ (fine, two, if you
include ~=). Remember, implicit conversion would only be one-way. From T to
string, not the other way around. Everything else is still the same.

3) That it breaks the statically typed system?
* This is a slippery-slope argument and it doesn't hold water. We are talking
about _one_ very special near-universal case which is strings. I think their use
is common enough that their ease of use and versatility should be made a
priority. 

4) That it hinders overloading?
* Personally, I think it's the opposite. It makes overloading simpler and more
concise. Nevertheless, if you still wanted to overload based on string, it would
still be possible.

Is there a real, compelling reason against calling toString automatically and
making everything have a toString? 

If there is, could someone provide a concrete example of it please?

Thanks,
--AJG.


How many characters do you  
save? There are a lot of other occasions where a special operator could be  
useful and save some keystrokes. But imagine that there actually were all  
these operators. Your code would be cluttered with things like ?&  or  !:   
or  *~  or  %do  etc. Thus there should be special operators for things  
that happen very often: index access, concatenation, addition, ... but not  
int to string conversion.

Ciao
uwe
Jul 12 2005
next sibling parent reply AJG <AJG_member pathlink.com> writes:
Ok, the solution to this problem depends on how the feature is implemented:

Case 1: No conversion goes on if types match.
Here calling fun(5) goes to the integer version.
To call the string version, you would have to do an explicit toString.

Case 2: Implicit conversion overrides.
Here calling fun (5) goes to the string version.
To call the int version, you would have to do an explicit cast (int) or
something like that.

Case 3: No ambiguity allowed.
Here the compiler would complain about such a case. Then,
To call the string version, you would have to do an explicit toString.
To call the int version, you would have to do an explicit cast (int) or
something like that.

I'm not sure which of these possibilities is the best; although I would prefer 1
or 2. If the feature is implemented, I'm sure all these things could be open to
suggestions and whatnot. Thought? Comments?

Thanks,
--AJG.


In article <db1eqo$1jbp$1 digitaldaemon.com>, Person says...

Mhm, i see some problems. int fun(int a) int fun(char []d)

fun(5)  which function to call.

Maybe make the conversion impicit for ~ operator

char []h 
int k
u=h~k

And unary ~ would be to convert to string too
like 
char []fun(){
int e;
return ~e;
}

Or is unary ~ already in use?




In article <db1dgr$1ht3$1 digitaldaemon.com>, AJG says...

Hi,


Still i do not see the benefit. If you like to write things short, do  
something like this:


alias toString toS;

char[] str1;
char[] str2;
int v;

str1 = str2 ~ toS(v);


These are 4 characters more you have to type. How often do you convert  
integers to strings in 100.000 lines of code? 


I agree that introducing a new operator for only int-to-string conversion is not
a good idea. In fact, I'd say it's a bad idea. We don't need a new operator for
this.

However, consider instead implicit conversion from any type to string. IMHO,
this type of conversion actually happens a _lot_ (or would you disagree?).

I think the right way of handling it is to add .toString properties to
primitives and then make toString be called automatically on conversion. 

This has several advantages:

1) It allows toString to handle some of the internalization issues (via locales,


2) It allows for this very much useful type of construct. In this case,
something like this could really help in debugging:





























Would this not be really useful? And what is the cost, really?
[Not that you said this, but in general]:

1) That you can confuse argument order in function calls?
* That can happen already with or without this feature. This is another issue
entirely (namely, the use named parameters) and it shouldn't masquerade against
string conversion.

2) That operators may not do what is expected?
* There is only _one_ operator to watch for, and that is ~ (fine, two, if you
include ~=). Remember, implicit conversion would only be one-way. From T to
string, not the other way around. Everything else is still the same.

3) That it breaks the statically typed system?
* This is a slippery-slope argument and it doesn't hold water. We are talking
about _one_ very special near-universal case which is strings. I think their use
is common enough that their ease of use and versatility should be made a
priority. 

4) That it hinders overloading?
* Personally, I think it's the opposite. It makes overloading simpler and more
concise. Nevertheless, if you still wanted to overload based on string, it would
still be possible.

Is there a real, compelling reason against calling toString automatically and
making everything have a toString? 

If there is, could someone provide a concrete example of it please?

Thanks,
--AJG.


How many characters do you  
save? There are a lot of other occasions where a special operator could be  
useful and save some keystrokes. But imagine that there actually were all  
these operators. Your code would be cluttered with things like ?&  or  !:   
or  *~  or  %do  etc. Thus there should be special operators for things  
that happen very often: index access, concatenation, addition, ... but not  
int to string conversion.

Ciao
uwe
Jul 12 2005
parent reply Kevin VR <save.kvr telenet.be> writes:
Hi,

I think that this is a very usefull feature.
It has clearly proven it's usefullness in Java, where this is used quite 
a lot i think.

fun(5); // This should go for the integer version, no conversion.
fun("" ~ 5); // This should go for the string version. Obviously.

So i think this is case 1, without the need for an explicit .toString() 
for the string version. The type it finally ends up being is used for 
the function call.

The number format problem can be solved using a different locale 
setting. Again just like in Java. Why is this different when just using
.toString() explicitly?

Thanks,
Kevin


AJG wrote:

 Ok, the solution to this problem depends on how the feature is implemented:
 
 Case 1: No conversion goes on if types match.
 Here calling fun(5) goes to the integer version.
 To call the string version, you would have to do an explicit toString.
 
 Case 2: Implicit conversion overrides.
 Here calling fun (5) goes to the string version.
 To call the int version, you would have to do an explicit cast (int) or
 something like that.
 
 Case 3: No ambiguity allowed.
 Here the compiler would complain about such a case. Then,
 To call the string version, you would have to do an explicit toString.
 To call the int version, you would have to do an explicit cast (int) or
 something like that.
 
 I'm not sure which of these possibilities is the best; although I would prefer
1
 or 2. If the feature is implemented, I'm sure all these things could be open to
 suggestions and whatnot. Thought? Comments?
 
 Thanks,
 --AJG.
 
 
 In article <db1eqo$1jbp$1 digitaldaemon.com>, Person says...
 

Mhm, i see some problems. int fun(int a) int fun(char []d)

fun(5)  which function to call.

Maybe make the conversion impicit for ~ operator

char []h 
int k
u=h~k

And unary ~ would be to convert to string too
like 
char []fun(){
int e;
return ~e;
}

Or is unary ~ already in use?




In article <db1dgr$1ht3$1 digitaldaemon.com>, AJG says...


Hi,



Still i do not see the benefit. If you like to write things short, do  
something like this:


alias toString toS;

char[] str1;
char[] str2;
int v;

str1 = str2 ~ toS(v);


These are 4 characters more you have to type. How often do you convert  
integers to strings in 100.000 lines of code? 


I agree that introducing a new operator for only int-to-string conversion is not
a good idea. In fact, I'd say it's a bad idea. We don't need a new operator for
this.

However, consider instead implicit conversion from any type to string. IMHO,
this type of conversion actually happens a _lot_ (or would you disagree?).

I think the right way of handling it is to add .toString properties to
primitives and then make toString be called automatically on conversion. 

This has several advantages:

1) It allows toString to handle some of the internalization issues (via locales,


2) It allows for this very much useful type of construct. In this case,
something like this could really help in debugging:





























Would this not be really useful? And what is the cost, really?
[Not that you said this, but in general]:

1) That you can confuse argument order in function calls?
* That can happen already with or without this feature. This is another issue
entirely (namely, the use named parameters) and it shouldn't masquerade against
string conversion.

2) That operators may not do what is expected?
* There is only _one_ operator to watch for, and that is ~ (fine, two, if you
include ~=). Remember, implicit conversion would only be one-way. From T to
string, not the other way around. Everything else is still the same.

3) That it breaks the statically typed system?
* This is a slippery-slope argument and it doesn't hold water. We are talking
about _one_ very special near-universal case which is strings. I think their use
is common enough that their ease of use and versatility should be made a
priority. 

4) That it hinders overloading?
* Personally, I think it's the opposite. It makes overloading simpler and more
concise. Nevertheless, if you still wanted to overload based on string, it would
still be possible.

Is there a real, compelling reason against calling toString automatically and
making everything have a toString? 

If there is, could someone provide a concrete example of it please?

Thanks,
--AJG.



How many characters do you  
save? There are a lot of other occasions where a special operator could be  
useful and save some keystrokes. But imagine that there actually were all  
these operators. Your code would be cluttered with things like ?&  or  !:   
or  *~  or  %do  etc. Thus there should be special operators for things  
that happen very often: index access, concatenation, addition, ... but not  
int to string conversion.

Ciao
uwe
Jul 16 2005
parent AJG <AJG_member pathlink.com> writes:
Hi,


The number format problem can be solved using a different locale 
setting. Again just like in Java. Why is this different when just using
.toString() explicitly?


Exactly. If anything, this feature could push towards improvements in toString
and co. to allow for better internationalization (that's a mouthful).

Cheers,
--AJG.
Jul 16 2005
prev sibling parent "Uwe Salomon" <post uwesalomon.de> writes:
 Or is unary ~ already in use?


Yes. Binary NOT.

Ciao
uwe
Jul 12 2005
prev sibling parent reply Dejan Lekic <leka entropy.tmok.com> writes:
I think You should give developers freedom to chose what they like - if they
want to write code that is hard to debug - let them do it - it is their
problem anyway.

Kind regards

Dejan

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
Jul 11 2005
next sibling parent Niko Korhonen <niktheblak hotmail.com> writes:
Dejan Lekic wrote:

 I think You should give developers freedom to chose what they like - if they
 want to write code that is hard to debug - let them do it - it is their
 problem anyway.


No, it's the maintenance engineer's problem :)
Jul 11 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Dejan Lekic" <leka entropy.tmok.com> wrote in message
news:dathls$vsq$1 digitaldaemon.com...

 I think You should give developers freedom to chose what they like - if


they

 want to write code that is hard to debug - let them do it - it is their
 problem anyway.


The problem with that is that implicit conversions will always be on, and
one can inadvertently fall into the hole.
Jul 11 2005
next sibling parent MicroWizard <MicroWizard_member pathlink.com> writes:
I agree with Walter regarding the balance of possibilities and constraints.

There is a big difference between these two things:
1.) Automatic conversion from integer to string in every cases.
2.) Give the possibility to the programmers to write easy string concatenation.

The first thing is very BAD for people who want to write reliable (not to
difficult to write, easy to read, easy to debug) code.

The second thing is a NEED for all programmer to write code quickly with the
consequences like debugging issues.

If anybody want to use "autoconverting" string class then one can write a simple
class with some overloaded operators. That's all, the resulting code could be so
short as it was in the first post. The possibility is here.
But we (at least I) do not want such MicroSoft (or Sun) like automagic thing.

Tamás Nagy


In article <daud1v$1qp9$1 digitaldaemon.com>, Walter says...

"Dejan Lekic" <leka entropy.tmok.com> wrote in message
news:dathls$vsq$1 digitaldaemon.com...

 I think You should give developers freedom to chose what they like - if


they

 want to write code that is hard to debug - let them do it - it is their
 problem anyway.


The problem with that is that implicit conversions will always be on, and
one can inadvertently fall into the hole.
Jul 11 2005
prev sibling next sibling parent Dejan Lekic <leka entropy.tmok.com> writes:
Walter I understand Your concerns, and apriciate Your work.

Recently I came to one great quote:

The language designer should be familiar with many alternative features
designed by others, and should have excellent judgment in choosing the best
and rejecting any that are mutually inconsistent... One thing he should not
do is to include untried ideas of his own. His task is consolidation, not
innovation. ---C.A.R. Hoare

I think You perfectly fit into this above. :)

Kind regards

Dejan

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
Jul 11 2005
prev sibling parent reply zhou gg.com writes:
In article <daud1v$1qp9$1 digitaldaemon.com>, Walter says...

The problem with that is that implicit conversions will always be on, and
one can inadvertently fall into the hole.


Two suggestions:

1) Don't solve this using a general approach, but only treat it as a specific
case for easy string concatenation, i.e. implicit conversions only happen on
toString() method.


2) Or, look at Python's approach:

sqlexec(" ... i = %d  f = %f ..." % (i, f));

It's kind of similar to formated printf, but more flexible.  Easy to write, easy
to read, and easy to maintain.

Just as syntatic sugar to:

char[256] buf;
sprintf(buf, " ... i = %d  f = %f ...", i, f);
sqlexec(buf);

I'd vote for the 2nd Python's approach.
Jul 11 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 2) Or, look at Python's approach:

 sqlexec(" ... i = %d  f = %f ..." % (i, f));


import std.string;
...
sqlexec(format("i = %d f = %f",i,f));
Jul 11 2005
parent reply z gg.com writes:
In article <davaot$2k7h$1 digitaldaemon.com>, Ben Hinkle says...

 2) Or, look at Python's approach:

 sqlexec(" ... i = %d  f = %f ..." % (i, f));


import std.string;
...
sqlexec(format("i = %d f = %f",i,f));


Ah, good to know it works! I hope this is close to what people asked to concat
string more easily.

Sometimes I think perl's approach of embedding variable directly in string is
also interesting:

sqlexec(" ... i = $i  f = $f ...");

of course you need an extra symbol '$' to indicate the variable.  But this
approach is not as inconvinient as to write the whole casting expression
explicitly, and is not as dangerous as implicit casting.  Probably something we
can also consider?
Jul 11 2005
next sibling parent M <M_member pathlink.com> writes:
sqlexec(" ... i = $i  f = $f ...");




Well it would be a good idea, but not in standard string. 

Lets make a specian string
sqlexec('" ... i = $i  f = $f ..."');

the special string would be between '" "'
And there could be many special thinks about this special string, starting that
you can write variables directly into it.




In article <davidq$2rk0$1 digitaldaemon.com>, z gg.com says...

In article <davaot$2k7h$1 digitaldaemon.com>, Ben Hinkle says...

 2) Or, look at Python's approach:

 sqlexec(" ... i = %d  f = %f ..." % (i, f));


import std.string;
...
sqlexec(format("i = %d f = %f",i,f));


Ah, good to know it works! I hope this is close to what people asked to concat
string more easily.

Sometimes I think perl's approach of embedding variable directly in string is
also interesting:

sqlexec(" ... i = $i  f = $f ...");

of course you need an extra symbol '$' to indicate the variable.  But this
approach is not as inconvinient as to write the whole casting expression
explicitly, and is not as dangerous as implicit casting.  Probably something we
can also consider?
Jul 12 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
<z gg.com> wrote in message news:davidq$2rk0$1 digitaldaemon.com...

 In article <davaot$2k7h$1 digitaldaemon.com>, Ben Hinkle says...

 2) Or, look at Python's approach:

 sqlexec(" ... i = %d  f = %f ..." % (i, f));


import std.string;
...
sqlexec(format("i = %d f = %f",i,f));


 Ah, good to know it works! I hope this is close to what people asked to 
 concat
 string more easily.

 Sometimes I think perl's approach of embedding variable directly in string 
 is
 also interesting:

 sqlexec(" ... i = $i  f = $f ...");

 of course you need an extra symbol '$' to indicate the variable.  But this
 approach is not as inconvinient as to write the whole casting expression
 explicitly, and is not as dangerous as implicit casting.  Probably 
 something we
 can also consider?


For completeness another way to write the above D example would be
sqlexec(format("i = ",i," f = ",f));
To me any of the above are pretty much equally readable.
Jul 12 2005
next sibling parent M <M_member pathlink.com> writes:
For completeness another way to write the above D example would be
sqlexec(format("i = ",i," f = ",f));
To me any of the above are pretty much equally readable. 



Ok, what happens when you mess up the order?


sqlexec(format("i = ",i,uups," f = ",f));

Can easyly happen, quite serious error and hard detect.



in article <db0b05$i7j$1 digitaldaemon.com>, Ben Hinkle says...

<z gg.com> wrote in message news:davidq$2rk0$1 digitaldaemon.com...

 In article <davaot$2k7h$1 digitaldaemon.com>, Ben Hinkle says...

 2) Or, look at Python's approach:

 sqlexec(" ... i = %d  f = %f ..." % (i, f));


import std.string;
...
sqlexec(format("i = %d f = %f",i,f));


 Ah, good to know it works! I hope this is close to what people asked to 
 concat
 string more easily.

 Sometimes I think perl's approach of embedding variable directly in string 
 is
 also interesting:

 sqlexec(" ... i = $i  f = $f ...");

 of course you need an extra symbol '$' to indicate the variable.  But this
 approach is not as inconvinient as to write the whole casting expression
 explicitly, and is not as dangerous as implicit casting.  Probably 
 something we
 can also consider?


For completeness another way to write the above D example would be
sqlexec(format("i = ",i," f = ",f));
To me any of the above are pretty much equally readable.
Jul 12 2005
prev sibling parent reply M <M_member pathlink.com> writes:
sqlexec(format("i = ",i," f = ",f));

Sorry I missunderstood you the first time.

Yes
sqlexec(format("i = ",i," f = ",f));
would work, but not for me.

With sql you must be very carefull not to paste the user input directly into the
code.

Fro me it is

msql("insert into TB (cc,kk) values($a,$b)","$a="~something,"$b="~somethingmore)

For me is the order very important, because

"$somethingtrusted="~somethinguntrusted

And here if the order woukd go corrupt the trusted and untrusted would switch
places.












In article <db0b05$i7j$1 digitaldaemon.com>, Ben Hinkle says...


<z gg.com> wrote in message news:davidq$2rk0$1 digitaldaemon.com...

 In article <davaot$2k7h$1 digitaldaemon.com>, Ben Hinkle says...

 2) Or, look at Python's approach:

 sqlexec(" ... i = %d  f = %f ..." % (i, f));


import std.string;
...
sqlexec(format("i = %d f = %f",i,f));


 Ah, good to know it works! I hope this is close to what people asked to 
 concat
 string more easily.

 Sometimes I think perl's approach of embedding variable directly in string 
 is
 also interesting:

 sqlexec(" ... i = $i  f = $f ...");

 of course you need an extra symbol '$' to indicate the variable.  But this
 approach is not as inconvinient as to write the whole casting expression
 explicitly, and is not as dangerous as implicit casting.  Probably 
 something we
 can also consider?


For completeness another way to write the above D example would be
sqlexec(format("i = ",i," f = ",f));
To me any of the above are pretty much equally readable.
Jul 12 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"M" <M_member pathlink.com> wrote in message 
news:db0nba$to7$1 digitaldaemon.com...

 sqlexec(format("i = ",i," f = ",f));

 Sorry I missunderstood you the first time.

 Yes
 sqlexec(format("i = ",i," f = ",f));
 would work, but not for me.

 With sql you must be very carefull not to paste the user input directly 
 into the
 code.


two things:
1) i is an int and f is a double so it isn't quite as bad as inserting an 
arbitrary string
2) I was just rewriting an example given by someone else about formating 
ints and floats - I have not idea what your actual API or requirements are.


 Fro me it is

 msql("insert into TB (cc,kk) 
 values($a,$b)","$a="~something,"$b="~somethingmore)

 For me is the order very important, because

 "$somethingtrusted="~somethinguntrusted

 And here if the order woukd go corrupt the trusted and untrusted would 
 switch
 places.


OK. My only point is that in D one can write "$a="~toString(something) or 
format("$a=",something) and you'll end up with the same thing. That's all I 
was trying to say. Sorry if it wasn't useful for your situation.
Jul 12 2005
prev sibling next sibling parent reply "Tony" <talktotony email.com> writes:
Can anyone provide an example which demonstrates the danger of implicit
conversion from an integer to a string?

Thanks,

Tony
Melbourne, Australia
Jul 11 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 12 Jul 2005 15:52:08 +1000, Tony <talktotony email.com> wrote:

 Can anyone provide an example which demonstrates the danger of implicit
 conversion from an integer to a string?


Essentially any situation where the programmer makes a small error by  
accidently using the wrong variable, a number, where a string is required.  
In essence a typo.

void foo(float f, double d, char[] string, char[] string2, int num = 1) {}
void main()
{
	int a = 5;
	char[] b = "test";
	foo(1.0,2.2,b,a); //oops meant foo(1.0,2.2,b,"",a);
}

The compiler does not error on the above it silently converts the number  
to a string. Imagine if the parameters had longer names than "a" and "b",  
imagine short constants were not used but longer variable names, imagine  
more distance between function/variable declaration and function call.

Regan
Jul 11 2005
prev sibling parent anonymous bosch <anonymous_member pathlink.com> writes:
In article <davlr5$2uo8$1 digitaldaemon.com>, Tony says...

Can anyone provide an example which demonstrates the danger of implicit
conversion from an integer to a string?

Thanks,


long ident;
void foo(char[] data)
{
 . . 
}
 . .
foo(msg ~ ident);  // Is this correct use of ident?

If 'ident' is implicitly converted to a string, it hides a potential mistake.
Did the author use the wrong variable? Did they mean to use 'ident' or something
else?

In the long run, and for the sake of maintence programmers everywhere, it pays
to be explicit about your intentions.

e.g.
foo(msg ~ toString(ident));  // Now this is unambiguous.
Jul 11 2005
prev sibling parent Mark D <theomnipotentqatmsn msn.com> writes:
M wrote:

 I am talking about automatic string conversion. 
 Even Java has it!
 
 char []s;
 int n;
 
 why not?
 s=s~n;
 
 This is one thing that java is far better than D, I must sadly say.
 
 Right now I have a line in my code:
 xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ",
 "$a="~toString(i1),"$b=
 "~toString(ids)));
 
 but why not
 xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ", "$a="~i1,"$b=
 "ids));
 
 Ok, I have 2 sql vars here, but what I had 10? What a mess would my code be.
 
 I know that automatic conversion might be a bit confusing, but it adds so much
 to the readability of code. 
 
 D has done so much to simplify reading and writing of code, why stop now?
 
 So why not?
 
 


If you look in the DDBI forum on dsource.org in the thread "writef type 
functionality" you will see that I have there a little function to help 
you to write code like this:

xchange(xmysql("UPDATE {0} SET id2 = {1} WHERE id = {2}", i1, ids));

I have found such a method acceptable.  Assuming that xmysql is a 
function you can hack up a bit.  Otherwise you'd have to include a 3rd 
function, but it'd still look better IMO.  If you are anti-squiggly you 
could change it to whatever, of course.

Mark D.
Jan 11 2006