The Weird and The Wonderful

16-Dec-19 5:59

In my Android app (using Kotlin) I recently had some code running even when the List of items contained 0 items.
I was using a for loop with a range and I expected that if the list(array or whatever) contained zero items then the count() would be zero and the for loop wouldn't run.

Here's a fake example of the code that actually runs. You can try it at the kotlin playground:
Kotlin Playground: Edit, Run, Share Kotlin Code Online[^]

Kotlin

val emptySet = Array<Int>(0){0}
println("There are ${emptySet.count()} items in the array.")
for (i in 0..emptySet.count()){
    println("Iniside the loop, one time.")
}

Here's the output:

There are 0 items in the array.
Iniside the loop, one time.

Kotlin

// So that would be the equivalent of:
for (i in 0..0){
    println("Iniside the loop, one time.")
}

I just didn't expect that would be how a range would work.
This feels different than the way C# would handle a for...loop like this.

But, again, I often stumble upon PEBKAC[^] errors. Roll eyes | :rolleyes:

I'm just lucky that way.

Richard Deeming16-Dec-19 8:49

Richard Deeming

16-Dec-19 8:49

That does seem rather odd, but it matches the description in the documentation:

Ranges and Progressions - Kotlin Programming Language[^]:
if (i in 1..4) {  // equivalent of 1 <= i && i <= 4
To iterate a number range which does not include its end element, use the until[^] function

Updating your example[^] to use until produces the expected result. Smile | :)

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

raddevus16-Dec-19 8:58

16-Dec-19 8:58

Richard Deeming wrote:
Updating your example[^] to use until produces the expected result.

That's fantastic!!! Thanks very much.
I wonder how I might've known that without reading all the documentation for Ranges.
Yes, I'm lazy. But, to me this indicates how Kotlin isn't intuitive because I have to know this other Range keyword (Until) where in the past I just iterate through integer values.
Said another way, "There is a way to intuit a range of integer values, but no way to intuit a keyword." But, alas, this is because I often write code before I understand the entire Universe of the Lanugage. Roll eyes | :rolleyes:

So, in the end, it is my fault. Blush | :O

TheGreatAndPowerfulOz16-Dec-19 9:05

16-Dec-19 9:05

The until keyword has nothing to do with ranges, it's just another way to write a classic for loop.

#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun

raddevus16-Dec-19 9:21

16-Dec-19 9:21

I just think in this case, for loops in C# are more intuitive and obvious:

// like 0..0 in Kotlin
// prints x 0
for (int x=0;x<=0;x++){
   Console.WriteLine($"x {x}");
}

// like 0 until 0 in Kotlin
// no output
for (int x=0;x<0;x++){
   Console.WriteLine($"x {x}");
}

Is there a more equivalent example (are there ranges in C#?) in C#?

TheGreatAndPowerfulOz16-Dec-19 10:05

16-Dec-19 10:05

foreach (var in list) { ... }

In C# 8 you have ranges:

foreach(var item in 1..100)
{
  Console.WriteLine(item);
}

For other range info see: (especially for arrays) C# 8 Ranges and Recursive Patterns[^]

raddevus16-Dec-19 10:16

16-Dec-19 10:16

TheGreatAndPowerfulOz wrote:
foreach (var in list) { ... }

Right, in C# it looks like this:

List<int> allInts = new List<int>();
Console.WriteLine($"There are  {allInts.Count} items in the list");
foreach (var x in allInts){
	Console.WriteLine(x);
}
//output : There are  0 items in the list

The code inside the foreach never runs. Again, that is more what I was expecting.

Richard Deeming17-Dec-19 0:28

Richard Deeming

17-Dec-19 0:28

TheGreatAndPowerfulOz wrote:
foreach(var item in 1..100)

That code won't work:

CS1579 foreach statement cannot operate on variables of type 'Range' because 'Range' does not contain a public instance definition for 'GetEnumerator'

And if you change it to iterate over a range of an array, the upper-bound is exclusive:

int[] numbers = Enumerable.Range(0, 20).ToArray();
foreach (int i in numbers[1..10])
{
    Console.WriteLine(i);
}

/*
Output:
1
2
3
4
5
6
7
8
9
*/

What's new in C# 8.0 - C# Guide | Microsoft Docs[^]:
The start of the range is inclusive, but the end of the range is exclusive, meaning the start is included in the range but the end isn't included in the range.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

TheGreatAndPowerfulOz17-Dec-19 5:05

17-Dec-19 5:05

Thanks, I guess the article from which I grabbed the code-snippet was from a proposed syntax. Too bad, it's much simpler and more readable than what does work.

I guess this is a little closer:

foreach(var item in Enumerable.Range(1, 10))
{
  Console.WriteLine(item);
}

TheGreatAndPowerfulOz16-Dec-19 9:02

16-Dec-19 9:02

Since a range is a set, and you're asking to iterate the set, then it's working exactly as I would have expected.

raddevus16-Dec-19 9:10

16-Dec-19 9:10

TheGreatAndPowerfulOz wrote:
Since a range is a set, and you're asking to iterate the set, then it's working exactly as I would have expected.

When I posted, I guessed that I'd get an answer like this. And, I'm not upset with your post, nor do I think it is incorrect.
I figured it was something I just didn't think entirely correctly about.

To me though, it seems like my original code was saying, iterate over this empty set and so I expected it to not run the code inside the for loop.
Another way to say this is, "I accept that I am incorrect about this, but the functionality of the structure as it is defined by Kotlin seems like it leads to grey understanding where the dev could be initially confused until dev obtains some experience with Kotlin Ranges."

But, again, I blame myself for not fully understanding the construct before using it.
I like to shoot first and ask questions later...after all the code is dead (not working). Laugh | :laugh:

Thanks for your input on this.

TheGreatAndPowerfulOz16-Dec-19 10:07

16-Dec-19 10:07

But the set from 0 to 0 is not empty, there is one item in it: 0.

If you'd said 0 to -1 (or 0 to count()-1 and assuming positive increment), then that would've been empty.

raddevus16-Dec-19 10:32

16-Dec-19 10:32

TheGreatAndPowerfulOz wrote:
But the set from 0 to 0 is not empty, there is one item in it: 0.

I agree with you on that. Just a very odd construct when thinking about iterating over a set of items. This gets weird when you are attempting to get an element out of the set that is based upon an index value.

Kotlin

for (i in 0..allItems.count){
    allItems.getItem(i);
}

I had fixed it using the notion that you mentioned (before I knew about Until), but it seemed odd

Kotlin

for (i in 0..allItems.count - 1){
    allItems.getItem(i);
}

crystalgecko18-Dec-19 23:44

crystalgecko

18-Dec-19 23:44

raddevus wrote:
thinking about iterating over a set of item

You are thinking about the wrong set. While you can iterate over the items with a forEach, your code is not doing this. Your code loops over a range from 0 to the length of your (empty) set (0).

My first thought when I encounter a range based set generating construct in a language is always "which if either (or both!) of the bounds is inclusive". You can test this with a quick implementation of the languages version of the following:

XML

for value in 1 to 3
    print value
done

kalberts19-Dec-19 0:28

kalberts

19-Dec-19 0:28

TheGreatAndPowerfulOz wrote:
But the set from 0 to 0 is not empty, there is one item in it: 0.

Usually, but not always.

The set of years from year 0 to year 0 is empty. Year -1 was immediately followed by year 1. There was no year 0.

Some people claim that this makes sense: There was no "year of Christ", the year before is birth was "year one before Christ" and the year after the birth was "year one". I have never met anyone who agrees that he was born in "year one before Christ", on Christmas day, neither will Christians agree that year one started 358 days before his birth. But the official view of the Christian church is that there was no year 0. This is so strong that even when non-Christians prefer to use the "Common Era" and "Before Common Era" rather than AD and BC, year 0 is skipped. Even in version 1.0 of the XML Schema language defined that for types date and dateTime, there is no year 0. (This definition was modified in later versions.)

The elevator in our office building is not very biblical of nature, yet there is no floor 0. It goes directly from floor 1 to floor -1. Since most of us are closer to mathematicians than to theologicans, to ease our minds we have declared that there is a floor 0, but it is virtual, and that is why the elevator doesn't stop there. Conceptually, it is there.

TheGreatAndPowerfulOz19-Dec-19 4:36

19-Dec-19 4:36

Since there is no year 0, then it's even worse than being the empty set, it's NULL.

As for your building, conceptually it is not there, so it is not an empty set, it is NULL.

Stuart Dootson19-Dec-19 7:52

Stuart Dootson

19-Dec-19 7:52

The difference between inclusive & exclusive ranges... You (and most of us, thanks to zero based arrays in C, C#, Javascript and the like) are used to exclusive ranges (not including the endpoint), but Kotlin's range notation produces inclusive ranges.

Rust has similar notation, but it produces exclusive ranges (as you were expecting Kotlin to do), and uses ..= for inclusive ranges, so:

rust

fn main() {
    for i in 0..=0 {
        print!("0..=0: {}\n", i);
    }
    for i in 0..0 {
        print!("0..0: {}\n", i);
    }
}

produces

0..=0: 0

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

raddevus19-Dec-19 8:24

19-Dec-19 8:24

Thanks for sharing that about Rust. I think that makes much more sense and is quite a bit more intuitively obvious.

I recently noticed that C# Enumerable.Range also works the way I would (intuitively) expect it to.

foreach (var index in Enumerable.Range( 0, 0 ))
{ 
   Console.WriteLine(index);
}
// produces no output