-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ring_span::push_front(), emplace_front(), pop_back() ? #99
Comments
I'm conflicted about adding API that would defeat the FIFO nature of the ring. I can see how they are "missing" from the interface when other containers are taken in to account, but the point of the ring is that you put something in to it, and then you take it out again, in order. The addition of these functions makes the interface easier to use incorrectly. Do you have some use cases for interfering with a ring in this way? |
The word 'ring' inherently does not convey any meaning with respect to a beginning or an ending. Has the name |
So then, among others, there are the forces of symmetry/asymmetry and easy to use/hard to misuse. |
My opinion is that we ought to provide them since they're cheap. (I can't think of anything that would make them expensive for any implementation to provide.) I'll note that our I do wonder whether something special ought to happen if you try to |
I don't really have a lot of input here, as inexperienced as I am with ring buffers, but the only thing I'd note is whatever behaviour is added should ideally follow the principle of least surprise, for end-user. M |
I'm not sure that cheap is a good enough reason to trump increased possibility of misuse, but perhaps we can let the committee decide. |
See Arthur O'Dwyer's reference implementation std::ring_span.
The text was updated successfully, but these errors were encountered: