On Monday, 9 May 2016 at 11:16:53 UTC, ZombineDev wrote:
> On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:
>> Don Clugston pointed out in his DConf 2016 talk that:
>>
>>     float f = 1.30;
>>     assert(f == 1.30);
>>
>> will always be false since 1.30 is not representable as a float. However,
>>
>>     float f = 1.30;
>>     assert(f == cast(float)1.30);
>>
>> will be true.
>>
>> So, should the compiler emit a warning for the former case?
>
> Yes, I think it is a good idea, just like emitting a warning for mismatched signed/unsigned comparison.

I agree for the float but not for the long/ulong comparisons.

I often do code like "x < array.length" where x needs to be a long to be able to handle negative values.

I want my code to compile without warning, and therefore I'm against requiring "x < array.length.to!long()" to remove that warning.

On Thursday, 29 June 2017 at 18:03:39 UTC, Ecstatic Coder wrote:
> I often do code like "x < array.length" where x needs to be a long to be able to handle negative values.
>
> I want my code to compile without warning, and therefore I'm against requiring "x < array.length.to!long()" to remove that warning.

`x < array.length` and `x < array.length.to!long` have different results when x is negative. That's why a warning/error is in order.

On Thursday, 29 June 2017 at 19:12:24 UTC, ag0aep6g wrote:
> On Thursday, 29 June 2017 at 18:03:39 UTC, Ecstatic Coder wrote:
>> I often do code like "x < array.length" where x needs to be a long to be able to handle negative values.
>>
>> I want my code to compile without warning, and therefore I'm against requiring "x < array.length.to!long()" to remove that warning.
>
> `x < array.length` and `x < array.length.to!long` have different results when x is negative. That's why a warning/error is in order.

I often have array indices that go up and down (x++/x--) depending on the logic.

I find convenient to be able to test them (x >= 0, x < a.length) without having to manage the fact that the array stores its length as an unsigned integer to double its potential size, since anyway I never use arrays with 2^63 items.

On Thursday, 29 June 2017 at 19:12:24 UTC, ag0aep6g wrote:
> On Thursday, 29 June 2017 at 18:03:39 UTC, Ecstatic Coder wrote:
>> I often do code like "x < array.length" where x needs to be a long to be able to handle negative values.
>>
>> I want my code to compile without warning, and therefore I'm against requiring "x < array.length.to!long()" to remove that warning.
>
> `x < array.length` and `x < array.length.to!long` have different results when x is negative. That's why a warning/error is in order.

I can perfectly understand that others may want to check their code in a "strict" mode.

So actually I'm not against a warning for signed/unsigned implicit conversions.

I'm just against putting it on by default, so that the current behavior is kept, because I don't see where is the language improvement in having to put these ugly manual conversion everywhere just because the string/array length was made unsigned.

I always use signed integers for string/array indices because unsigned indices become dangerous as soon as your algorithm starts to decrement it...

And as I said, I compile my D code with the 64-bit compiler, and 2^63 characters/items is much more than needed for my personal use cases.

So until the day I will have a computer which can store a string of 16 million terabytes, at the moment I prefer to use long values for indices, instead of ulong, because negative indices can already occur right now with my current algorithms.

On 06/30/2017 07:38 AM, Ecstatic Coder wrote:
> I'm just against putting it on by default, so that the current behavior is kept, because I don't see where is the language improvement in having to put these ugly manual conversion everywhere just because the string/array length was made unsigned.

So what you really want is: signed array lengths. You only have a use for the sloppy conversion, because D doesn't have signed array lengths.

> I always use signed integers for string/array indices because unsigned indices become dangerous as soon as your algorithm starts to decrement it...

I guess they're "dangerous" because you get ulong.max instead of (a signed) -1? But that's exactly what happens with the implicit conversion, too.

At some point you have to think of that. Either when adding/subtracting or when comparing signed with unsigned. With a warning/error on the implicit conversion, you'd get a nice reminder.

By the way, std.experimental.checkedint may interesting:

----
import std.experimental.checkedint: checked, ProperCompare,
    Saturate;

/* If negative values should not occur, throw an error on wrap
around: */
auto x = checked(size_t(0));
--x; /* error */

/* Or stop at 0: */
auto y = checked!Saturate(size_t(0));
--y; /* does nothing */
assert(y == 0); /* passes */

/* If negative values are valid, you can use proper comparisons
without sloppy implicit conversions or verbose manual ones: */
auto z = checked!ProperCompare(int(-1));
auto array = [1, 2, 3];
assert(z < array.length); /* passes */
----

> So what you really want is: signed array lengths. You only have a use for the sloppy conversion, because D doesn't have signed array lengths.

Yes and no. Signed safety is better, but the current behavior works too.

Honestly I don't care if the bit maniacs want 8 million terabytes more for their strings, as long as I can safely ignore that implementation detail.