# Enumerable for function(2)

**URL:** <https://forum.elixirforum.com/t/enumerable-for-function-2/29573>\
**Category:** Questions\
**Tags:** standard-library\
**Created:** [March 3, 2020, 11:30am UTC](https://forum.elixirforum.com/t/enumerable-for-function-2/29573 "2020-03-03T11:30:14Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![josevalim](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/josevalim/32/1787_2.png) [@josevalim](https://forum.elixirforum.com/u/josevalim)\
**Post date:** [March 10, 2020, 11:42am UTC](https://forum.elixirforum.com/t/enumerable-for-function-2/29573/18 "2020-03-10T11:42:52Z")

</div>

I think there is a confusion on the arguments being made here.

1. 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

2. The argument that using `function(2)` is somewhat _more_ dangerous is incorrect though. The issue that can be triggered with `function(2)` would also help if we wrapped it in a `Stream` or any other struct, because Streams are fundamentally about passing continuations of code around and changing it from `function(2)` to `Stream` won’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.

---

_[View the full topic](https://forum.elixirforum.com/t/enumerable-for-function-2/29573)._