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. Before I do, do we all agree on the following:
1. All higher order ranges should use auto ref. 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. If so, these standards should be published somewhere to discourage the kind of inconsistency that's developed due to sheer confusion about what the "right" answers to these issues are. On Wed, Jun 23, 2010 at 1:20 PM, Max Samukha <[email protected]> wrote: > > > On Wed, Jun 23, 2010 at 5:01 PM, David Simcha <[email protected]> wrote: > >> Isn't that the point of @property? I just followed what Andrei was >> doing. If there's anywhere where I didn't put @property in, it's purely an >> unintentional oversight. Please let me know and/or fix it. >> >> I don't have commit access to phobos. DummyRange.front on line 1644 and > DummyRange.save (1647) should be properties, I believe. Also, 'front' on > line 1553. > > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
