arikai
Enumerable for function(2)
In the recent EEF SWG it was pointed out that function(2) has support for Enumerable protocol.
While it’s obvious that “the vulnerability” can be exploited the same way with the Streams, what is still curious to me is the following.
Why is there implementation for a such type in the first place?
During some digging in the commits via git blame it was found that defimpl was added to support then-called Enum.Iterator (now it’s just Enumerable) and was basically what Streams are for nowadays: lazy sequences.
But now we have Streams, yet this piece of code still exists. Shouldn’t it be removed?
I believe responses from the Core team might be useful here.
Most Liked Responses
josevalim
I think there is a confusion on the arguments being made here.
-
The argument that using
function(2)can be the cause of confusion - because I can accidentally pass it around as a enumerable is a valid one -
The argument that using
function(2)is somewhat more dangerous is incorrect though. The issue that can be triggered withfunction(2)would also help if we wrapped it in aStreamor any other struct, because Streams are fundamentally about passing continuations of code around and changing it fromfunction(2)toStreamwon’t fix it.
So while the first argument 1 is valid and has some merit - it is not a major improvement to justify changing the current feature set. Maybe there could be other benefits in making them more structured - but if there are, I am not aware of them at the moment.
I don’t think it would make the implementation easier to digest as well. As ultimately the difference would be that a function would return Stream.stream(&foo(&1, &2)) instead of &foo(&1, &2). Streams are naturally complex, given the fact they provide zipping, filtering, and protection against dangling resources. Wrapping an anonymous function call in a remote call or not is not going to do much to counter that.
benwilson512
I think it’s a mistake to think of a Stream as a single kind of datastructure. What exists is an Enumerable protocol, and then Enum functions to consume those Enumerables eagerly, and Stream functions to consume those Enumerables lazily. Absolutely anything that implements the Enumerable protocol is Enumerable. The standard library, mostly for I think easier pattern matching and IO.inspect purposes, has created some Stream named structs to represent certain constructs that have been built in a way that is amenable to streaming. That doesn’t mean that that fits every scenario however.
It’s also worth keeping in mind Elixir compatibility guarantees. At best you could deprecate the use of 2 arity functions as enumerables, but you can’t eliminate it without breaking people’s code that relies on this.
hauleth
Yes:
iex(1)> Stream.unfold(5, fn
...(1)> 0 -> nil
...(1)> n -> {n, n - 1}
...(1)> end) |> is_function(2)
true








