# \`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:** 1\
**Showing post:** 22

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

---

_[View the full topic](https://discourse.julialang.org/t/eachrow-over-array-any-2-does-not-return-rows-why/34601)._