<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 23-mar-10, at 21:51, Andrei Alexandrescu wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 03/23/2010 03:46 PM, Steven Schveighoffer wrote:<br><blockquote type="cite">On Tue, 23 Mar 2010 16:34:24 -0400, Andrei Alexandrescu<br></blockquote><blockquote type="cite"><<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>> wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><font class="Apple-style-span" color="#540000">[...]</font></blockquote><blockquote type="cite">A while back, you identified one of the best interfaces for input ranges:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">E* getNext();<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Which allows for null returns when no data is left. The drawback is that<br></blockquote><blockquote type="cite">E must be either referenced or allocated on the heap (providing storage<br></blockquote><blockquote type="cite">to the function is an option). But the killer issue was that safeD would<br></blockquote><blockquote type="cite">not allow it. However, in recent times, you have hinted that safeD may<br></blockquote><blockquote type="cite">allow pointers, but disallow bad pointer operations. In light of this,<br></blockquote><blockquote type="cite">can we reconsider this interface, or other alternatives using pointers?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I've always felt that if we were to define ranges for streams in a<br></blockquote><blockquote type="cite">non-awkward way, we would need an "all in one" operation, since not only<br></blockquote><blockquote type="cite">does getting data from the range move the range, but checking for empty<br></blockquote><blockquote type="cite">might also move the range (empty on a stream means you tried to read and<br></blockquote><blockquote type="cite">got nothing).<br></blockquote></div></blockquote><div><br></div>yes that also makes filters/combiners really nice to write.</div><div>the basic thing is that you have to return two things, 1. if there is more and 2. if yes the element.</div><div><br><blockquote type="cite"><div>I'd gladly reconsider E* getNext(), and I like it a lot, but that doesn't accommodate ranges that want to return rvalues without storing them (e.g. a range using getchar() as a back-end, and generally streams that don't correspond to stuff stored in memory). If it's not in memory, there's no pointer to it.<br></div></blockquote><div><br></div><div>E* getNext would probably also be workable, at the cost of storing one element. But then as andrei correctly points out one still cannot expect the pointer to be valid after one iteration, so as soon as you don't have memory storage you loose thread safety...</div><div><br></div><div>Now reentrancy/thread safety is not necessarily the most important thing for iterators, but I like that my queues, sources of work can have the same interface.</div></div><br></body></html>