first() and last() on empty ranges

[JeffBezanson]

first and last give errors for other collections where they're defined, but not for ranges. In typical uses, f(first(r), length(r)) is called, and since length(r)==0 nothing bad happens.

[JeffBezanson]

One idea: code that uses first(r) on possibly-empty ranges could use r.start instead. After all, it is currently depending on a specific, arguably-incorrect behavior of this type, so it might as well explicitly depend on the representation.

[quinnj]

Is this really a problem in practice? I guess the main problem here is that when you call first(r) or last(r) on a collection, you would assume what you get back are valid elements of that collection. On the other hand, ranges are kind of a different beast because the empty range has a special representation that technically includes a start and stop, as meaningless as they may be.

I think my vote would be to leave it as is. Anyone working with ranges in a more nuanced way than for i = 1:10 quickly learns about the need for isempty(r) as a critical part of asserting valid ranges.

[toivoh]

I would vote to fix this; the current behavior is breaking the abstractions
of first and last. This is not limited to code that was written with ranges
in mind; i think that code that was written with any iterable container in
mind should work also with ranges.

[toivoh]

Also, agree with Jeff that code that wants to depend on the implementation
details of ranges might as well admit it; by accessing fields or some
range-specific interface.

[ivarne]

If we "fix" this, and folks uses Jeff's solution, their code will be broken for FloatRange's where divisor is not equal to 1.

[Jutho]

I would favor not to fix this. I use this actively. I use UnitRange{Int} to indicate a region of a one-dimensional lattice. I use a range of zero length to indicate something living on the edge between the two neighboring vertices, e.g. n:n-1 indicates an object living on the edge between vertex n-1 and vertex n. In this code, the use of first and last fits naturally and extends all the way from the zero length case to the case with nonzero length.

A range n:n-1 still contains some nontrivial information, i.e. the value of n. This is different from an empty vector [] which contains absolutely nothing. In that sense they are different. Unless you prefer to automatically reset all empty ranges to some standard value 0:-1 as well?

[ivarne]

Empty ranges are also used in splice! to indicate insertion

[JeffBezanson]

Just as well that empty ranges are not == to empty vectors.

[toivoh]

Ok, I see that there's a number of uses for the current behavior as long as you know that you're working on ranges. But how would you write the documentation for first and last? Would it be ok to introduce something like rangestart and rangeend (better names?) functions for this?

[Jutho]

I am all for generality and consistency, so I don't mind that first and last get changed, as long as another implementation-independent functionality is provided for getting this information out of a range. In fact, I guess it is mostly UnitRange{Int}, or maybe StepRange{Int} which are also useful when empty, so it might be ok to restrict this functionality to these cases.

[StefanKarpinski]

Worth contemplating is that if you want the error-throwing behavior v[1] and v[end] work just fine.