make eltype throw for some known noniterators

[nsajko]

Neither Nothing or Missing are iterators, iterate(nothing) throws: thus eltype should throw for such arguments as well.

[vtjnash]

I don't believe there is anything about not implementing iteration or getindex which implies that eltype needs to throw or return anything particularly special

[vtjnash]

The PR also breaks a handful of tests, so it is probably not worth considering

[nsajko]

I don't believe there is anything about not implementing iteration or getindex which implies that eltype needs to throw or return anything particularly special

It's better to throw than to return an incorrect result silently. Any possible return value is incorrect, given that a non-iterator doesn't have an element type. Thus throwing seems to be left as the only option.

The PR also breaks a handful of tests, so it is probably not worth considering

I haven't yet looked through all or even most of these, but I'm not disheartened by what I've seen yet. Some of the test failures are benign things, such as @test_throws test that check for a hardcoded error message.

[ararslan]

Any possible return value is incorrect, given that a non-iterator doesn't have an element type.

I'm not sure that's true in general: surely there are examples in the ecosystem of containers that don't implement iteration but have a meaningful notion of element(s) and thus element type.

There's also nothing special about nothing and missing in this regard. For example, iterate is not implemented for Symbol but eltype works.

It's better to throw than to return an incorrect result silently.

I'm somewhat ambivalent about how nothing is handled here but IMO eltype(missing) === Any makes sense. A missing value means there is a value, we just don't know what it is. That value could be a scalar or container with a meaningful element type, but we don't know for certain, so Any is a logical answer.

I haven't looked at the failing tests but this feels like it has the potential to be more breaking than it appears. FWIW, the generic fallback for eltype returning Any in the absence of a more specific method dates back to 2013, before the release of Julia v0.2. I have to imagine that it's become a pretty deep-seated assumption.

[nsajko]

eltype(missing) === Any makes sense

I agree, now that you pointed it out, given the special, missing data, semantics of missing. However I still think something like eltype(Missing) should throw, given that Missing is not an iterator type.

I'm not sure that's true in general: surely there are examples in the ecosystem of containers that don't implement iteration but have a meaningful notion of element(s) and thus element type.

In that case I guess such a "container" would better use some other function instead of eltype. Perhaps I'm not seeing the big picture or something, but as far as I understand eltype is a basic part of the iteration interface, as documented in Interfaces in the Manual. So any other use of eltype would be harmful punning.

[ararslan]

Can a function not be part of two interfaces?

[martinholters]

Any possible return value is incorrect, given that a non-iterator doesn't have an element type.

Eh, Union{} might be considered a correct return value, indicating that trying to obtain an element will error.