Proposal: takeFront and takeBack
Christophe Travert
travert at phare.normalesup.org
Tue Jul 3 10:31:21 PDT 2012
takeFront implementation is dangerous for ranges which invalidates their
front value when popFront is called, for instance, File.byLine. Thus
takeFront will have to be used with care: any range implement takeFront
(because of the template and USFC), but it may not be valid. That makes
the range interface more complicated: There is a takeFront property, but
you have to check it is safe to use... how do you check that by the way?
Are there so many ranges that duplicate efforts in front and popFront,
where there is no easy workarround? Would it be such an improvement in
performance to add takeFront? strings being immutable, my guess would be
that it is not that hard for the compiler to optimize a foreach loop (it
should be easy to profile this...). Even if there is an efficiency
issue, you could easily solve it by implementing a range wrapper or an
opApply method to make foreach faster.
--
Christophe
More information about the Digitalmars-d
mailing list