# \`eachrow\` over Array{Any, 2} does not return rows, why?

**URL:** <https://discourse.julialang.org/t/eachrow-over-array-any-2-does-not-return-rows-why/34601>\
**Category:** General Usage\
**Created:** [February 13, 2020, 8:58pm UTC](https://discourse.julialang.org/t/eachrow-over-array-any-2-does-not-return-rows-why/34601 "2020-02-13T20:58:34Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 14, 2020, 4:26pm UTC](https://discourse.julialang.org/t/eachrow-over-array-any-2-does-not-return-rows-why/34601/21 "2020-02-14T16:26:13Z")

</div>

I agree with @Tamas_Papp that anticipating every possible user expectation in the warnings becomes too much trouble at some point. However, for the basic arithmetic operations (`+`,`-`,`*`,`/`,`^`) and functions (`sqrt`, `exp`, `log`) on elementary `Number` and `AbstractArray` types, I think it would be reasonable to put some extra effort into the warnings. These are some of the first situations where new users will encounter differences from Numpy/R/Matlab, and it is an opportunity to teach them the Julia semantics.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [February 14, 2020, 7:34pm UTC](https://discourse.julialang.org/t/eachrow-over-array-any-2-does-not-return-rows-why/34601/22 "2020-02-14T19:34:50Z")

</div>

> [@Tamas\_Papp](#):
>
> The cost is not one-time: these messages have to be kept up to date, preserved when the code changes (eg in case of a refactoring), unit tested, and maintained.

I do know this. I am familiar with software development. Yet, this is the kind of method that demands least amount of work possible. Both `eachcol` and `eachrow` need more maintenance than this, but exist.

> [@Tamas\_Papp](#):
>
> If we do this consistently, all kinds of suggestions from the language can be reasonable requested whenever someone is surprised about something.

I cannot see a problem if this is done consistently and with a good reasoning (i.e., the maintenance cost is expected to be worth the help to newcomers). Moreover, if there is a flood of requests of this kind that have no merit, well, they will be denied, I trust the ability of JuliaLang developers to say no.

> [@Tamas\_Papp](#):
>
> I am not sure why you think this is a bug, it isn’t — as pointed out above by @stevengj, it is consistent with how slicing works in Julia.

I think I was not clear enough. The bug they find is the wrong use of `eachrow` when they wrongly assume it returns a row. So the bug is in their code. I think the existence of `eachcol` (in its current fashion) is maybe a design mistake, but I would not call it a bug as it seems very clear now that it was intended to be this way.

> [@Tamas\_Papp](#):
>
> so it is very difficult to guess what someone intended in a specific context

Yes. However, I find that, in this specific context, of an user trying to multiply two unidimensional arrays the changed error message will make the problem clear to the user in 90%+ of the cases, while I can hardly see a situation where the old error message would be better.

> [@Tamas\_Papp](#):
>
> effort is better spent on adding examples to docstrings, and making interfaces or consistent.

Never said it was not, and even suggested that `eachrow` could be clearer in its docstring about how it does not return a row from a matrix (or even change the term `view` to `view to an Array{Any, 1}`). This does not preclude creating this error message in this specific case.

@stevengj We agree. My idea was never to do this to every possible mistake involving the standard library that a programmer can do. Monday or Tuesday I will make a PR if none of my lab colleagues want to do it themselves.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [February 22, 2020, 10:17am UTC](https://discourse.julialang.org/t/eachrow-over-array-any-2-does-not-return-rows-why/34601/23 "2020-02-22T10:17:03Z")

</div>

Another issue is that the docstring of `eachrow` is simply

> Create a generator that iterates over the first dimension of vector or matrix A, returning the rows as views.

Reading this, I would expect `eachrow` to return a `1xN` matrix view. This is also heavily implied by the function name.

**Edit:** Actually, the function name is fine, but combined with the docstring, I find it confusing.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 22, 2020, 3:45pm UTC](https://discourse.julialang.org/t/eachrow-over-array-any-2-does-not-return-rows-why/34601/24 "2020-02-22T15:45:57Z")

</div>

Made a PR that clarifies the docstrings. I think that this resolves the issue.

[https://github.com/JuliaLang/julia/pull/34845](https://github.com/JuliaLang/julia/pull/34845)

[Previous page](https://discourse.julialang.org/t/eachrow-over-array-any-2-does-not-return-rows-why/34601.md?page=1)