Thread overview
Should negating an unsigned integral be an error?
Jan 29, 2018
Dave Jones
Jan 29, 2018
Jonathan M Davis
Jan 30, 2018
Michael
Jan 30, 2018
bauss
Jan 30, 2018
Michael
January 29, 2018
Given

uint i = 12345;

should

writeln(-i)

be an error? or maybe i should be automatically cast to a larger signed type?
January 29, 2018
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

January 30, 2018
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.
January 30, 2018
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.
January 30, 2018
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.