"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:k81k6s$1qm7$1...@digitalmars.com... > On 11/14/12 5:30 PM, Daniel Murphy wrote: >> "Andrei Alexandrescu"<seewebsiteforem...@erdani.org> wrote in message >> news:k80l8p$397$1...@digitalmars.com... >>> On 11/14/12 7:29 AM, H. S. Teoh wrote: >>>> But since this isn't going to be fixed properly, then the only solution >>>> left is to arbitrarily declare transient ranges as not ranges (even >>>> though the concept of ranges itself has no such implication, and many >>>> algorithms don't even need such assumptions), and move on. We will just >>>> have to put up with an inferior implementation of std.algorithm and >>>> duplicate code when one*does* need to work with transient ranges. It >>>> is >>>> not a big loss anyway, since one can simply implement one's own library >>>> to deal with this issue properly. >>> >>> What is your answer to my solution? >>> >>> transient elements == input range&& not forward range&& element type >>> has >>> mutable indirections. >>> >>> This is testable by any interested clients, covers a whole lot of >>> ground, >>> and has a good intuition behind it. >>> >>> >>> Andrei >> >> Is it just me, or would this still refuse: >> array(map!"a.dup"(stdin.byLine())) ? > > It would accept mapping to!string. > > Andrei >
Is that really good enough? Keeping ranges simple is important, but so is making the obvious solution 'just work'.
