is this considered inconsistency?

Mar 21, 2021

Steven Schveighoffer

Mar 21, 2021

Dennis

Mar 21, 2021

Paul Backus

Mar 21, 2021

Mar 23, 2021

Imperatorn

https://run.dlang.io/is/VOGlGN void main() { import std.stdio: writeln; { // example from "Introduction to Algorithms" Cormen et al., p 146 int[] a = [ 4, 1, 3, 2, 16, 9, 10, 14, 8, 7 ]; foreach (i; 0 .. 1 ) writeln(i); // 0 foreach (i; 0 .. 0 ) writeln(i); // no output foreach (i; 0 .. -1 ) writeln(i); // no output foreach (i; a[0 .. 1]) writeln(i); // 4 foreach (i; a[0 .. 0]) writeln(i); // no output foreach (i; a[0 .. -1]) writeln(i); // Range violation } } Why can't the a[0 .. -1] just return empty range, when end <= start, as in a[0 .. 0]? and also in foreach (i; 0 .. -1 )?

On 3/21/21 11:55 AM, mw wrote: > https://run.dlang.io/is/VOGlGN > > void main() > { > import std.stdio: writeln; > { > // example from "Introduction to Algorithms" Cormen et al., p 146 > int[] a = [ 4, 1, 3, 2, 16, 9, 10, 14, 8, 7 ]; > > foreach (i; 0 .. 1 ) writeln(i); // 0 > foreach (i; 0 .. 0 ) writeln(i); // no output > foreach (i; 0 .. -1 ) writeln(i); // no output > > foreach (i; a[0 .. 1]) writeln(i); // 4 > foreach (i; a[0 .. 0]) writeln(i); // no output > foreach (i; a[0 .. -1]) writeln(i); // Range violation > } > } > > Why can't the a[0 .. -1] just return empty range, when end <= start, as in a[0 .. 0]? and also in foreach (i; 0 .. -1 )? > > That would be the least useful behavior. -Steve

On Sunday, 21 March 2021 at 16:21:44 UTC, Steven Schveighoffer wrote: > On 3/21/21 11:55 AM, mw wrote: >> https://run.dlang.io/is/VOGlGN >> >> void main() >> { >> import std.stdio: writeln; >> { >> // example from "Introduction to Algorithms" Cormen et al., p 146 >> int[] a = [ 4, 1, 3, 2, 16, 9, 10, 14, 8, 7 ]; >> >> foreach (i; 0 .. 1 ) writeln(i); // 0 >> foreach (i; 0 .. 0 ) writeln(i); // no output >> foreach (i; 0 .. -1 ) writeln(i); // no output >> >> foreach (i; a[0 .. 1]) writeln(i); // 4 >> foreach (i; a[0 .. 0]) writeln(i); // no output >> foreach (i; a[0 .. -1]) writeln(i); // Range violation >> } >> } >> >> Why can't the a[0 .. -1] just return empty range, when end <= start, as in a[0 .. 0]? and also in foreach (i; 0 .. -1 )? >> >> > > That would be the least useful behavior. It's useful (to be consistent): it reduces user's burden to write the bound check explicitly (verbosely), i.e foreach (i; a[0 .. max(0, end)]) {...}

On Sunday, 21 March 2021 at 15:55:04 UTC, mw wrote: > Why can't the a[0 .. -1] just return empty range, when end <= start, as in a[0 .. 0]? and also in foreach (i; 0 .. -1 )? In `foreach (i; 0 .. -1)`, `i` is typed `int`. In a slice, the indices are of type `size_t` which is an unsigned integer type. -1 underflows to `ulong.max` (on 64-bit) which is why you get a range violation. You could define your own slice type as a struct with operator overloads, where you can use signed indices or automatic clamping of the bounds or whatever you want. Changing the behavior of the language type would be a breaking and possibly controversial change. There's also a point to be made that the implicit conversion from signed to unsigned integers should not be allowed, that's a separate discussion.

On Sunday, 21 March 2021 at 16:47:41 UTC, Dennis wrote: > On Sunday, 21 March 2021 at 15:55:04 UTC, mw wrote: >> Why can't the a[0 .. -1] just return empty range, when end <= start, as in a[0 .. 0]? and also in foreach (i; 0 .. -1 )? > > In `foreach (i; 0 .. -1)`, `i` is typed `int`. In a slice, the indices are of type `size_t` which is an unsigned integer type. -1 underflows to `ulong.max` (on 64-bit) which is why you get a range violation. Ahh, This explains. > There's also a point to be made that the implicit conversion from signed to unsigned integers should not be allowed, that's a separate discussion. Indeed, this shouldn't be allowed, bite by this a number of times. Is there a DIP on this already?

On Sunday, 21 March 2021 at 17:01:27 UTC, mw wrote: >> There's also a point to be made that the implicit conversion from signed to unsigned integers should not be allowed, that's a separate discussion. > > Indeed, this shouldn't be allowed, bite by this a number of times. Is there a DIP on this already? There have been proposals to change the integer promotion rules in the past, but they've been rejected because Walter wants to keep them compatible with C, to make porting C code to D easier.

On Sunday, 21 March 2021 at 21:22:16 UTC, Paul Backus wrote: > On Sunday, 21 March 2021 at 17:01:27 UTC, mw wrote: >>> There's also a point to be made that the implicit conversion from signed to unsigned integers should not be allowed, that's a separate discussion. >> >> Indeed, this shouldn't be allowed, bite by this a number of times. Is there a DIP on this already? > > There have been proposals to change the integer promotion rules in the past, but they've been rejected because Walter wants to keep them compatible with C, to make porting C code to D easier. "compatible with C" as a goal of D? Then why we need D? C++ has been there already 😎 Instead of let a few people decide, how about also let the users decide? I have read -dipxxx switches are kind of previews (not formally in to the language). How about add a -dip-no-explicit-conversion preview, but ask the users permission to send their actuall complier build flags (of their daily work) back to dlang.org, and let that statistics be part of the decision factor? E.g, if 99.999% of the users always have that flag turned on, why not have that feature into the language?