Iterator protocol

[codehz]

It seems the current for loop only accept this form iterator

function iter(input: any): (function(input: any, state: any): (boolean, any, any), any, any)

Why not make it more generalize?

accept this

function iter(input: any): (function(<PART-A>): <PART-B>, <PART-A>)

and PART-A can be any tuple, also for PART-B's tuple

example:

function iter(input: integer): (function(state: *iter_state): integer, iter_state) ... end
--- usage
for value in iter(5) do print(value) end
--- transform to
local fn, state = iter(5)
local running = true
local value = integer()
while true do
  running, value = fn(state)
  if not running then
    break
  end
  print(value)
end

[codehz]

Oh, I see the problem, it may be a breaking change
The current iterator protocol return the index that's will be feed to next iteration, but in my proposal, no parameter pass to the original function..

[edubart]

Indeed, the current iterator design requires to pass the current iterator index to the function returned by the iterator. But if you don't use that parameter (because maybe you embed it in the state), you can just ignore it and the C compiler will hopefully optimize away the unused variable.

I see what you wanted there, I've thought the same thing when making the hashmap iterator, there the key parameter is unused, but I've opted to leave like that because trying to remove it would lead to some undesired consequences with the compiler late type deduction system.

[codehz]

I didn't see any type deduction problem ¯_(ツ)_/¯
As you can see, in my example, all local variable (except for the value, but it can be easily solved by moving into the loop) has no explicit typing.
The state's type are determined at first, so no 'late type deduction', it just get type from right to left

Modified example to avoid explicit type:

local fn, state = iter(5)
while true do
  local running, value = fn(state)
  if not running then
    break
  end
  print(value)
end