www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - operator "~" does not check type?

reply Cheng Wei <rivercheng gmail.com> writes:
The following expression compiles but does not make sense.

string str = "hello" ~ 10;
assert(str == "hello\n");

Is this a useful feature or just a bug?
Oct 12 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Cheng Wei:


 string str = "hello" ~ 10;
 assert(str == "hello\n");
 
 Is this a useful feature or just a bug?


I'd call it trash-feature :-|

Bye,
bearophile
Oct 12 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, October 12, 2011 07:08:05 Cheng Wei wrote:

 The following expression compiles but does not make sense.
 
 string str = "hello" ~ 10;
 assert(str == "hello\n");
 
 Is this a useful feature or just a bug?


int and dchar implicitly convert to one another for better or for worse. 
Personally, I'd prefer that they didn't, but that's the way that it is, so I 
don't believe that this is technically a bug.

- Jonathan M Davis
Oct 12 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 int and dchar implicitly convert to one another for better or for worse. 
 Personally, I'd prefer that they didn't, but that's the way that it is, so I 
 don't believe that this is technically a bug.


char->int is OK, but int->char is not so OK. This programs (that compiles with
no errors) seems to show a possible source of bugs, so I call this a design
bug, worth fixing:


void main(string[] args) {
    int x = args.length;
    string s = "hello";
    s ~= x;
}


Bye,
bearophile
Oct 12 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, October 12, 2011 03:53:22 bearophile wrote:

 Jonathan M Davis:

 int and dchar implicitly convert to one another for better or for worse.
 Personally, I'd prefer that they didn't, but that's the way that it is,
 so I don't believe that this is technically a bug.


 
 char->int is OK, but int->char is not so OK. This programs (that compiles
 with no errors) seems to show a possible source of bugs, so I call this a
 design bug, worth fixing:
 
 
 void main(string[] args) {
     int x = args.length;
     string s = "hello";
     s ~= x;
 }


I believe that the primary reasoning for allowing the implicit conversion 
between int and dchar is so that code like this

dchar c = 'a' + 7;

doesn't require a cast. So, the primary target is converting to int to dchar. 
Regardless, when it's come up before, Walter has been very much against 
changing it.

- Jonathan M Davis
Oct 12 2011
parent reply Trass3r <un known.com> writes:
 I believe that the primary reasoning for allowing the implicit conversion
 between int and dchar is so that code like this

 dchar c = 'a' + 7;


That's a '+' though, not a '~'.

I think it shouldn't be allowed with ~ since it's misleading.
Newbies would probably expect "abc" ~ 10 to yield "abc10" rather than the  
odd "abc\n".
Oct 12 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 12 Oct 2011 09:46:57 -0400, Trass3r <un known.com> wrote:


 I believe that the primary reasoning for allowing the implicit  
 conversion
 between int and dchar is so that code like this

 dchar c = 'a' + 7;


 That's a '+' though, not a '~'.


Jonathan meant this better example ;)

string s = "hello";
s ~= 'a' + 7;


 I think it shouldn't be allowed with ~ since it's misleading.
 Newbies would probably expect "abc" ~ 10 to yield "abc10" rather than  
 the odd "abc\n".


100% agree.  Requiring a cast in order to convert to dchar is a small  
price to pay (not that common to do arithmetic with characters) for  
avoiding surprising compilations.

-Steve
Oct 12 2011
parent reply Cheng Wei <rivercheng gmail.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 On Wed, 12 Oct 2011 09:46:57 -0400, Trass3r <un known.com> wrote:

 I believe that the primary reasoning for allowing the implicit
 conversion
 between int and dchar is so that code like this

 dchar c = 'a' + 7;


 That's a '+' though, not a '~'.


 Jonathan meant this better example ;)
 string s = "hello";
 s ~= 'a' + 7;


It's still fine if '~' does not allow implicit casting but '+' does.
'a' + 7 -> 'h' which is already a dchar. So it can be appended to s
without casting.

Now the question is how easy it is to allow implicit casting for some
operators but not other operators.



 I think it shouldn't be allowed with ~ since it's misleading.
 Newbies would probably expect "abc" ~ 10 to yield "abc10" rather




than

 the odd "abc\n".


 100% agree.  Requiring a cast in order to convert to dchar is a


small

 price to pay (not that common to do arithmetic with characters) for
 avoiding surprising compilations.
 -Steve
Oct 13 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 13 Oct 2011 06:57:09 -0400, Cheng Wei <rivercheng gmail.com> wrote:


 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 On Wed, 12 Oct 2011 09:46:57 -0400, Trass3r <un known.com> wrote:

 I believe that the primary reasoning for allowing the implicit
 conversion
 between int and dchar is so that code like this

 dchar c = 'a' + 7;


 That's a '+' though, not a '~'.


 Jonathan meant this better example ;)
 string s = "hello";
 s ~= 'a' + 7;


 It's still fine if '~' does not allow implicit casting but '+' does.
 'a' + 7 -> 'h' which is already a dchar. So it can be appended to s
 without casting.


A + B where the types of A and B are integral goes through integer  
promotion rules, inherited from C.  Like them or not, they are very  
unlikely to change.  This means dchar + int promotes to int, not dchar.

I think requiring a cast to go from int to dchar would be fine.  It's not  
a very common operation, and it clearly causes novice issues.

-Steve
Oct 13 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/13/2011 01:46 PM, Steven Schveighoffer wrote:

 On Thu, 13 Oct 2011 06:57:09 -0400, Cheng Wei <rivercheng gmail.com> wrote:


 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 On Wed, 12 Oct 2011 09:46:57 -0400, Trass3r <un known.com> wrote:

 I believe that the primary reasoning for allowing the implicit
 conversion
 between int and dchar is so that code like this

 dchar c = 'a' + 7;


 That's a '+' though, not a '~'.


 Jonathan meant this better example ;)
 string s = "hello";
 s ~= 'a' + 7;


 It's still fine if '~' does not allow implicit casting but '+' does.
 'a' + 7 -> 'h' which is already a dchar. So it can be appended to s
 without casting.


 A + B where the types of A and B are integral goes through integer
 promotion rules, inherited from C. Like them or not, they are very
 unlikely to change. This means dchar + int promotes to int, not dchar.


Actually uint afaik.


 I think requiring a cast to go from int to dchar would be fine. It's not
 a very common operation, and it clearly causes novice issues.


Another argument for requiring an explicit cast is that not every int 
can be converted to a valid dchar.
Oct 16 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 16 Oct 2011 18:24:26 -0400, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 10/13/2011 01:46 PM, Steven Schveighoffer wrote:

 On Thu, 13 Oct 2011 06:57:09 -0400, Cheng Wei <rivercheng gmail.com>  
 wrote:


 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 On Wed, 12 Oct 2011 09:46:57 -0400, Trass3r <un known.com> wrote:

 I believe that the primary reasoning for allowing the implicit
 conversion
 between int and dchar is so that code like this

 dchar c = 'a' + 7;


 That's a '+' though, not a '~'.


 Jonathan meant this better example ;)
 string s = "hello";
 s ~= 'a' + 7;


 It's still fine if '~' does not allow implicit casting but '+' does.
 'a' + 7 -> 'h' which is already a dchar. So it can be appended to s
 without casting.


 A + B where the types of A and B are integral goes through integer
 promotion rules, inherited from C. Like them or not, they are very
 unlikely to change. This means dchar + int promotes to int, not dchar.


 Actually uint afaik.


Hm... int can hold all dchar values, so I'd expect it to promote to int  
before uint.

testing:

void main()
{
     dchar d;
     auto x = d + 5;
     pragma(msg, typeof(x).stringof);
}

outputs: uint

so you are right!  Seems like an oversight...

-Steve
Oct 17 2011
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 12/10/2011 09:53, bearophile a écrit :

 Jonathan M Davis:


 int and dchar implicitly convert to one another for better or for worse.
 Personally, I'd prefer that they didn't, but that's the way that it is, so I
 don't believe that this is technically a bug.


 char->int is OK, but int->char is not so OK. This programs (that compiles with
no errors) seems to show a possible source of bugs, so I call this a design
bug, worth fixing:


In D, the conversion is implicit if the compiler can detect it is same 
via bound checking. Here, the compiler can deduce that the int 10 is 
between 10 and 10 so can be safely converted.
Oct 12 2011