Open fdwr opened 11 months ago
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!
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. ⏳👂...
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 ;-)
I had similar thoughts while watching that talk.
- 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.
- '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.
- 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".
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?
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.
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
I came here from your recent talk "A Safer Iteration Model for C++ - Tristan Brindle - C++ on Sea 2023", and generally I like it. 😎
The naming of
is_last
though is confusing because it's not testing whether the current points to the last thing, but rather whether it points after the last thing. The namefirst
is fine for the starting point, but for the stopping point, you really want to know whether the cursor is at the limit (like limits in math, an element one past which is not actually ever reached). I considered possible alternate names 🤔:is_limit
(not too long and very clear, that you'reat
thelimit
)is_past
(coincidentally rhymes withis_last
for the one-past 😉)is_done
(works, but then it's counterpartflux::done()
counterpart doesn't sound so nice)is_stopped
(would use pairsflux::start()
andflux::stop()
, which sounds a bit weird, but not weirder than begin/end)is_complete
(hmm, maybe)is_terminated
(bit long)is_terminal
(maybe)(oops, C++ keyword, so can't use that)is_final
And conversely for the counterpart of
flux::first(v)
:flux::limit(v)
(noun works well here)flux::past(v)
(clearly evokes the "one past" concept)flux::done(v)
(😕 hmm, sounds weird because it sounds like a boolean function rather than returning a one-past sentinel marker)flux::stop(v)
(can be a noun like "gradient stop" or a verb, where verb is weird like "end")flux::complete(v)
(😕 also sounds like weird like done)flux::terminal(v)
(but not to be confused with a command line interface 😅)(oops, C++ keyword, so can't use that)flux::final(v)
And yes, using any of the above counterparts above would not form a pair like
first
andlast
do, but then end-exclusive ranges are already an asymmetric concept[ )
.From your talk, where you say "That's called chain in my library, because that's a better name" and "sum, because that's easier to spell than accumulate", I can see you're not strongly attached to existing names. Do any of the above alternate names convey the concept for you nicely, especially
limit
orpast
, because if the 62 upvotes from here mean anything, usinglast
is an non-ideal name? Cheers from Seattle.