www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should negating an unsigned integral be an error?

reply Dave Jones <dave jones.com> writes:
Given

uint i = 12345;

should

writeln(-i)

be an error? or maybe i should be automatically cast to a larger 
signed type?
Jan 29 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, January 29, 2018 09:58:00 Dave Jones via Digitalmars-d wrote:
 Given

 uint i = 12345;

 should

 writeln(-i)

 be an error? or maybe i should be automatically cast to a larger
 signed type?
It arguably should be, but it's pretty common in C/C++ to get uint.max with -1, and I suspect that it's fairly common in D as well even though you could just use uint.max. So, it could be argued either way. - Jonathan M Davis
Jan 29 2018
parent reply Michael <michael toohuman.io> writes:
On Monday, 29 January 2018 at 10:06:41 UTC, Jonathan M Davis 
wrote:
 On Monday, January 29, 2018 09:58:00 Dave Jones via 
 Digitalmars-d wrote:
 Given

 uint i = 12345;

 should

 writeln(-i)

 be an error? or maybe i should be automatically cast to a 
 larger signed type?
It arguably should be, but it's pretty common in C/C++ to get uint.max with -1, and I suspect that it's fairly common in D as well even though you could just use uint.max. So, it could be argued either way. - Jonathan M Davis
I'd like to see these kinds of potential mistakes to be forced to use something like uint.max. Of course, at this point it might be too late to introduce something as breaking as this, but these kinds of things should definitely be forced by the language, or made a warning at least, pointing to the use of .max instead.
Jan 30 2018
parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 30 January 2018 at 11:09:08 UTC, Michael wrote:
 On Monday, 29 January 2018 at 10:06:41 UTC, Jonathan M Davis 
 wrote:
 On Monday, January 29, 2018 09:58:00 Dave Jones via 
 Digitalmars-d wrote:
 Given

 uint i = 12345;

 should

 writeln(-i)

 be an error? or maybe i should be automatically cast to a 
 larger signed type?
It arguably should be, but it's pretty common in C/C++ to get uint.max with -1, and I suspect that it's fairly common in D as well even though you could just use uint.max. So, it could be argued either way. - Jonathan M Davis
I'd like to see these kinds of potential mistakes to be forced to use something like uint.max. Of course, at this point it might be too late to introduce something as breaking as this, but these kinds of things should definitely be forced by the language, or made a warning at least, pointing to the use of .max instead.
A normal deprecation process should be enough, since it'll give time to update code that uses it. I don't think there is a lot of idiomatic D code that uses this feature.
Jan 30 2018
parent Michael <michael toohuman.io> writes:
On Tuesday, 30 January 2018 at 14:08:41 UTC, bauss wrote:
 On Tuesday, 30 January 2018 at 11:09:08 UTC, Michael wrote:
 On Monday, 29 January 2018 at 10:06:41 UTC, Jonathan M Davis 
 wrote:
 On Monday, January 29, 2018 09:58:00 Dave Jones via 
 Digitalmars-d wrote:
 Given

 uint i = 12345;

 should

 writeln(-i)

 be an error? or maybe i should be automatically cast to a 
 larger signed type?
It arguably should be, but it's pretty common in C/C++ to get uint.max with -1, and I suspect that it's fairly common in D as well even though you could just use uint.max. So, it could be argued either way. - Jonathan M Davis
I'd like to see these kinds of potential mistakes to be forced to use something like uint.max. Of course, at this point it might be too late to introduce something as breaking as this, but these kinds of things should definitely be forced by the language, or made a warning at least, pointing to the use of .max instead.
A normal deprecation process should be enough, since it'll give time to update code that uses it. I don't think there is a lot of idiomatic D code that uses this feature.
But it's one of those bad habits lots of people have probably gotten into because it was the way to do things in C/C++ or whatever. Good point, though. I think it would be worth catching all of these small potential errors that can be replaced with code that is much more clear as to its intent.
Jan 30 2018