On Wed, 29 Sep 2010 13:40:49 -0400, dsimcha <[email protected]> wrote:
I somewhat agree, but apparently noone noticed my other post.
moveFront() and
friends **have default behavior** via the module level function
std.range.moveFront() in most cases, and when they don't it is for a
good reason.
If Phobos directly calls the object's moveFront() instead of using the
module
level one with this default behavior, then IMHO it's **a bug**. Please
read my
post from ~an hour ago on this default behavior.
I did see your other post. From reading the docs for moveFront and
friends, it appears that you are supposed to leave the original in a
default "empty shell" state. But that makes no sense in terms of simple
types, like an int, or some POD struct. Am I wrong on this?
But I agree with the gist of your post -- I should not have to define
moveFront and friends if it makes no sense to.
One problem I see here is, unless your range is specific to the element
type, you have to deal with moveFront and friends. Because someone could
use an element type that wants a moveFront-style swap. And this will
almost certainly be boilerplate code. where's that std.mixins module? :)
The easiest thing, and probably the most appropriate, is to just return
ref from my Deque range. That avoids having to define moveFront, and sort
still works with it. As far as danger of exposing internals, I'm not
manually managing the memory anyways (it just uses array appending).
But on a higher-level note, I feel ranges are becoming more complex than
I'd like. The first time I heard of a range, it was a simple wrapper for
two iterators. Soon, you might need a whole book to determine how to
properly implement ranges so they fit into the correct algorithms. It
would appear to be enough to just statically assert a range is a certain
type, but I think you might actually have to assert that it's not other
types. Duck typing is great for using libraries, but it's a pain for
writing them.
-Steve
