[phobos] phobos commit, revision 1689

Philippe Sigaud philippe.sigaud at gmail.com
Wed Jun 23 13:20:08 PDT 2010


On Wed, Jun 23, 2010 at 19:36, David Simcha <dsimcha at gmail.com> wrote:

> Ok, so I'll probably have time soon to do a serous cleanup of all these
> nagging @property and auto ref issues and improve the unittests in std.range
> and std.algorithm, across everything, not just the couple ranges that I
> worked on recently.  I'm sick enough of all these little nagging issues that
> make ranges hard to use in D that I'm willing to devote some significant
> effort towards solving them.


Oh, nice call! I'm also getting tired of putting comments around the refs,
release after release, to make ranges in phobos accept one another. I'd be
glad to be of help, if I can (though with two children sick right now, I
don't promise to get enough sleep to be useful)


> Before I do, do we all agree on the following:
>
> 1.  All higher order ranges should use auto ref.
>

My own tentative auto refs for std.range didn't change the lvalue/rvalue
issues :(


> 2.  front(), empty(), back(), length() and save() are @property.
> 3.  popFront(), popBack(), and moveFront() are *NOT* @property.
> 4.  Higher order ranges should check for infinite-ness of the ranges
> they're operating on and propagate it (using enum bool empty = false instead
> of a function that propagates empty) where it makes sense, for example in
> Map and Filter.
>
>
I'd even go as far as saying that HOR should propagate their input's
properties as much as possible, as you did with bug 2872 (hmm, I didn't find
that a few months ago, that's why I posted 3871).
Also, bug 3872.

Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100623/8e44caa5/attachment.html>


More information about the phobos mailing list