Today I committed and pushed my code implementing "for" loops for my pet #programminglanguage, #rocket.
So, if an object has an `__iter__` method and the object returned by that has a `__next__` method, you can now write:
```
for x in my_object:
...
```
So far I haven't implemented the `else` branch (that's supported by #Python), because I'm not sure how useful/common that actually is.
Also, so far the syntax is limited to a single variable, unpacking something (e.g. `for i, x in enumerate(my_object)`) is not yet supported.
I feel like half of the effort/code went into handling the new variable `x`. It can optionally be declared with a type (e.g. `for x: int64 in my_object`), in which case it will be treated as a *new* variable (that exists only inside the loop). If you *omit* the type, it imitates the behaviour of an assignment statement (i.e. `x = ...`).
In that case, it either
- uses an existing variable or
- creates a new variable or
- throws a `TypeError`.
While writing test-cases I also discovered a bug elsewhere in my code:
Two of my new test cases (for the for loops) check that the for loop can work with `__iter__` and `__next__` methods of a different type. E.g. if you have a type `A`, type `B` inherits from type `A`, and the `__iter__` method was declared with a parameter of type `A` (rather than `B`), you should still be able to write `for x in B(): ...`, because the object of `B` is also an instance of `A`, so you should be able to call `__iter__` with a parameter of type `B`, too.
(As another example, `__iter__()` could have an optional, second parameter, and it should still work in a for loop.)
Anyway. While writing these test cases, I discovered the bug that (currently) you cannot actually declare a variable with a fixed type if that type is a `protocol`. The reason is that so far my code assumed that every type has a *default value*. (E.g.: the default value of ints is 0, the default value of boolean is `False`.) However, that doesn't make sense for *protocols*, since
a) there's no guarantee there is a type implementing the protocol when the variable is created (there's not even a guarantee there will ever be a type implementing the protocol) and
b) even if there where many types implementing the protocol, it wouldn't make sense to arbitrarily choose one of them and initialise the variable with the default value of that type. That would be completely random guesswork.
I guess I'll have to drop the assumption that every type has a default value, but...
That was a nice assumption, because it made life *so much* easier.
Consider for example creating an array of type `T`. If `T` has a default value, there's no issue, you just allocate the array and initialise all the items in the array with the default value, then let the programmer do with it as (s)he pleases. There is no risk the programmer might use uninitialised memory. If `T` does *not* have a default value... You'd have to make sure that every item in the array gets initialised *by the programmer*.
But what if the programmer wants to create an `ArrayList[T]`? In that case the programmer *naturally* wants to over-allocate a bit, e.g. create an array (backing the list) with space for 16 (or so) elements, even when the list doesn't actually contain any items, yet. Again, if `T` has a default value, you can handle it safely, just initialise all the array items immediately after allocation. If `T` doesn't have a default value, you can't really initialise the array items when allocating the array, you have to rely on the programmer to do so. But then you want to make sure that every no array item is *read* before it has been initialised *by the programmer*, *somehow*. (I don't really have an idea how.)