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.
>
>

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.
>>>
>>>
>>
>>
>
>

"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.

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

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

> 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

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

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

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
>
>

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
>>
>>
>
>