> 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

> Or is unary ~ already in use?

Yes. Binary NOT.

Ciao
uwe

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,
>>>or parameters, or something like C#'s Culture class, etc.)
>>>
>>>2) It allows for this very much useful type of construct. In this case,
>>>something like this could really help in debugging:
>>>
>>># void dbg(string s) { fwritefln(stderr, "DEBUG: %s", s); }
>>># ...
>>># void main() {
>>>#     int i;
>>>#         ...
>>>#     dbg(i);
>>>#
>>>#     float f;
>>>#         ...
>>>#     dbg(f);
>>>#
>>>#     double d;
>>>#         ...
>>>#     dbg(d);
>>>#
>>>#     real r;
>>>#         ...
>>>#     dbg(r);
>>>#
>>>#     Foo c = new Foo;
>>>#         ...
>>>#     dbg(a);
>>>#
>>>#     byte[] b = new byte[];
>>>#         ...
>>>#     dbg(b);
>>># }
>>>
>>>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
>>>
>>>
>>
> 
> 

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.

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.