On Thu, Mar 27, 2014 at 05:11:55PM -0700, Walter Bright wrote: > On 3/27/2014 3:48 PM, Timon Gehr wrote: > >Maybe empty/front/popFront should just be a single primitive, like: > >Nullable!T get(); > > What if get() fails?
That's the whole point of Nullable!T: you can return null if get() fails. I can't say I like this, though. There are many cases in my code that need separation of .empty from .front from .popFront, such as recursive descent parsers or code that does if-match-then-consume algorithms. One of the *nice* things about the current range API is that that code works with arrays, streams, and lots of other stuff, without needing to care about implementation details. Changing it to get() will require lots of manual buffering and reintroduce lots of ugly boilerplate that I had to live with in C++. I'm with Walter on this one. Generic code should NOT assume anything about a range it was given, and therefore it should call .empty before calling .front or .popFront. If you "know" that a particular range doesn't require calling .empty beforehand, then by definition your code is no longer generic, and you just have to live with the consequences of that. Nothing stops you, for example, from exposing a .get function or whatever else, *in addition* to the standard range API. Then code that knows how to deal with .get will use it, and your range remains usable with other generic code. Nothing about the range API dictates that .empty cannot do useful work like initialize buffers. That should be an implementation detail that generic code shouldn't rely on. T -- The early bird gets the worm. Moral: ewww...
