is_last naming bikeshed about flux

[tcbrindle]

Hi, thanks for filing the issue! As it happens, I was thinking about this as well after I saw that Reddit thread.

In my defence, the name last makes more sense if you think about it as meaning "the last cursor position" rather than "a cursor pointing to the last element" -- since a sequence with N elements has N+1 possible cursor positions. That said, I'm not particularly strongly attached to it, and I can see that there is an ambiguity that isn't ideal.

Back when I started working on the library, cursors were called indices and the sequence functions were called begin_idx(), end_idx() and is_done(). If we went back to using the term "index" rather than "cursor" then I think these function names are pretty good... but the whole reason I changed in the first place was that "index" has strong associations with integers whereas "cursor" makes it clear that in Flux it's a more general concept, so I don't know how I'd feel about changing back now.

Of the names you suggest (thank you for coming up with a list!), I think we actually could use final, because it's not a true keyword and wouldn't conflict with anything. It might be my favourite, in fact. I also like limit as it conveys the past-the-end-ness very nicely.

I'd be keen to get more feedback on this before changing anything so if anyone has any suggestions or preferences then please leave a comment!

[nuuSolutions]

I had similar thoughts while watching that talk.

1. I always considered end() being one past the end a naming smell.
   Testing against end() to see if find() has a result is just crazy imo.
   But one got used to it. With 'end' being kind of an abstract term it seems fine.

2. 'first' and 'last', however, sound much more concrete, (even more so than front and back) so the abstraction that last is one past the last is much much harder.

3. If I were to reinvent this, I would probably choose to get rid of is_last() anyway in favor for the iterator simply being invalid. I would also have last() wrap the last valid index. After 25+ years of STL brainwash, nobody would like that, though ;-)

[marktsuchida]

Python uses start and stop for half-open index ranges (as well as other things, though not 100% consistently), and I remember it being much more immediately clear on first sight compared to C++'s begin and end, to the inexperienced programmer that I was at the time. I also do think that it helps to use two words that are a natural pair in English. is_stop() might have an advantage in that it grammatically forces "stop" to be taken to be a noun, which then nudges you to recognize that it is a term with a specific meaning -- but that might just be for me.

Just came to this repo from your wonderfully presented CppNorth talk.

[fdwr]

if you think about it as meaning "the last cursor position ... That said ... I can see that there is an ambiguity

Yeah, thinking in terms of possible valid index values, last is/was reasonable.

I think we actually could use final

True, it's a contextual keyword. 🤔

I'd be keen to get more feedback

Certainly, leaving it open a while for further comments is wise. Thanks for listening. ⏳👂...

[tcbrindle]

I had similar thoughts while watching that talk.

1. I always considered end() being one past the end a naming smell.
   Testing against end() to see if find() has a result is just crazy imo.

"Did we find what we were looking for or did we reach the end of our search range" isn't all that crazy IMO. And in any case, Flux has flux::contains which just returns a bool if that's what you want.

But one got used to it. With 'end' being kind of an abstract term it seems fine.
2. 'first' and 'last', however, sound much more concrete, (even more so than front and back) so the abstraction that last is one past the last is much much harder.
3. If I were to reinvent this, I would probably choose to get rid of is_last() anyway in favor for the iterator simply being invalid. I would also have last() wrap the last valid index. After 25+ years of STL brainwash, nobody would like that, though ;-)

If you use closed rather than half-open ranges then it means you can't call first() or last() on an empty sequence. So then you need to make is_empty() a customisation point instead of is_last() and have all algorithms check for that, and so you haven't actually simplified anything. This is similar to what D ranges does, which is an interesting model but less powerful and not what I want to do for Flux. Half-open ranges, with their natural treatment of empty sequences, are here to stay I'm afraid -- and it's certainly not "brainwashing".

[nuuSolutions]

sigh
I was just trying to make the point that a random person would guess (with odds>80%) that - given a list - begin and end refer to the first and last elements. Now what might these odds be if we replaced begin, end with first, last?

[fdwr]

I'd be keen to get more feedback on this before changing anything so if anyone has any suggestions or preferences then please leave a comment!

Rewatching your CppCon talk tonight (Iteration Revisited: A Safer Iteration Model for Cpp - Tristan Brindle) reminded me of this issue. Is half a year enough time for feedback collection? :b