On Friday, 20 September 2013 at 15:09:57 UTC, Dmitry Olshansky
wrote:
20-Sep-2013 18:13, Szymon Gatner пишет:
On Friday, 20 September 2013 at 14:04:06 UTC, Dmitry Olshansky
wrote:
>> Can't a container be a range as well?
>>
>For Christ sake no, no and no.
[... Because that would be ...]
> TL;DR: Suboptimal, unnatural and error prone are keywords.
Then your question - Why would it be suboptimal?
Which your second reply seem to clearly explain: extra state
placed
where it doesn't belong. I can't easily correlate your two
answers as
they look as if the second one answers questions of the first.
Anyhow we are in agreement here.
Mind that "Can't a container be a range as well?" was not from
me.
Yup, but it was what I was answering ... when you asked about
why would it be suboptimal... A container that is a range at
the same time is suboptimal, that's all.
Still, moving computation over a range from for loop body into
the range
implementation (like filtering) incurs no performance penalty
and has
additional benefits of composability and maintainability. Do
you mean
that is suboptimal?
I made no statement on this I think. It shouldn't be
ineffective.
The only problem with it that I foresee is that in order to
take advantage of vectorized SIMD in CPU it could be harder to
auto-magically vectorize such code for compiler.
For that matter I think e.g. providing explicitly a range of
float4 fells like a better way to go.
Yup, we agree then :) I think I add to confusion also because I
think about C++ and not D. I didn't realize that arrays/slices
are ranges in D. That is not good indeed.
