www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - is this considered inconsistency?

reply mw <mingwu gmail.com> writes:
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 )?
Mar 21
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Mar 21
parent mw <mingwu gmail.com> writes:
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)]) {...}
Mar 21
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
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.
Mar 21
parent reply mw <mingwu gmail.com> writes:
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?
Mar 21
parent reply Paul Backus <snarwin gmail.com> writes:
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.
Mar 21
parent reply mw <mingwu gmail.com> writes:
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?
Mar 21
parent reply mw <mingwu gmail.com> writes:
On Sunday, 21 March 2021 at 22:56:43 UTC, mw wrote:
 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?
Typo: -dip-no-implicit-conversion
Mar 21
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 21 March 2021 at 22:59:26 UTC, mw wrote:
 On Sunday, 21 March 2021 at 22:56:43 UTC, mw wrote:
 On Sunday, 21 March 2021 at 21:22:16 UTC, Paul Backus wrote:
 [...]
"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?
Typo: -dip-no-implicit-conversion
It would probably have to be the other way around though. Begin by having a --allow-implicit-conversion, then after x amount of time it could possibly be default. But this is a major thing so I doubt it
Mar 23