I've been having fun with ranges lately. While nesting computing ranges I
noticed only the
outermost range's cache is necessary; there's no way of accessing front() of
ranges deeper
in the expression twice because they are sealed by the outermost range. Example:
map!"a._0 + a._1"(// caches
On 10/09/2010 09:38 PM, Tomek Sowiński wrote:
I've been having fun with ranges lately. While nesting computing ranges I
noticed only the
outermost range's cache is necessary; there's no way of accessing front() of
ranges deeper
in the expression twice because they are sealed by the outermost ra
On 9/10/10 8:58 PM, Pelle wrote:
How about never having caches and if you need them, you can get a
cached(map(..etc..))?
I do not understand where the notion that ranges should have caches come
from. It destroys the possibility for using const and complicates the
writing of them.
I agree with
Pelle napisał:
> On 10/09/2010 09:38 PM, Tomek Sowiński wrote:
>> I've been having fun with ranges lately. While nesting computing ranges I
>> noticed only the outermost range's cache is necessary; there's no way of
>> accessing front() of ranges deeper in the expression twice because they
>> are
On 10/9/10 14:38 CDT, Tomek Sowiński wrote:
I've been having fun with ranges lately. While nesting computing ranges I
noticed only the
outermost range's cache is necessary; there's no way of accessing front() of
ranges deeper
in the expression twice because they are sealed by the outermost rang
On 10/9/10 15:12 CDT, Peter Alexander wrote:
On 9/10/10 8:58 PM, Pelle wrote:
How about never having caches and if you need them, you can get a
cached(map(..etc..))?
I do not understand where the notion that ranges should have caches come
from. It destroys the possibility for using const and co
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 10/9/10 14:38 CDT, Tomek Sowiński wrote:
> > I've been having fun with ranges lately. While nesting computing ranges I
noticed only the
> > outermost range's cache is necessary; there's no way of accessing front() of
r
On 9/10/10 11:40 PM, Andrei Alexandrescu wrote:
I think it's a good idea. In fact let's eliminate caching altogether; it
does not happen for the random access operator anyway and I think it's
fair to simply evaluate the function whenever an element is accessed.
Whaddaya think?
Andrei
Yep, kill
On 10/9/10 18:20 CDT, dsimcha wrote:
Vote++. When I added bidirectional support for map(), I felt like any solution
for doing bidirectional caching was going to suck. I considered just
eliminating
it, but left it because at the time I was more interested in just getting
bidirectional/random ac
On Sat, 09 Oct 2010 18:43:54 -0500, Andrei Alexandrescu wrote:
> On 10/9/10 18:20 CDT, dsimcha wrote:
>> Vote++. When I added bidirectional support for map(), I felt like any
>> solution for doing bidirectional caching was going to suck. I
>> considered just eliminating it, but left it because a
Peter Alexander napisał:
> On 9/10/10 8:58 PM, Pelle wrote:
>> How about never having caches and if you need them, you can get a
>> cached(map(..etc..))?
>>
>> I do not understand where the notion that ranges should have caches come
>> from. It destroys the possibility for using const and complica
On 9/10/10 10:06 PM, Tomek Sowiński wrote:
How can I contribute that to Phobos?
I believe you have been accepted as a trusted commiter by some people
(Walter and Andrei?). Most people appear to earn trust by writing a high
quality library.
On 10/9/10 16:06 CDT, Tomek Sowiński wrote:
Peter Alexander napisał:
On 9/10/10 8:58 PM, Pelle wrote:
How about never having caches and if you need them, you can get a
cached(map(..etc..))?
I do not understand where the notion that ranges should have caches come
from. It destroys the possibil
Peter Alexander:
> I believe you have been accepted as a trusted commiter by some people
> (Walter and Andrei?). Most people appear to earn trust by writing a high
> quality library.
Right. While DMD is currently NOT managed as a true Open Source project (and
this is very bad for the future an
14 matches
Mail list logo
