Transient ranges

[Dicebot via Digitalmars-d]

On Tuesday, 14 June 2016 at 00:19:54 UTC, Andrei Alexandrescu 
wrote:
> On 06/12/2016 04:46 AM, Dicebot wrote:
>> That is matter of design philosophy. For me such basic library
>> primitives warrant C++ attitude of "don't pay for what you 
>> don't ask
>> for" - and everything else, including actual feature 
>> completeness, is of
>> negligible importance compared to that.
>
> C++'s input iterator model also predicates multiple accesses to 
> the current value by means of *it.

Yeah, I don't say C++ iterator model is any better for that kind 
of design - sorry if my wording implied that. I wonder how they 
would address it if pipeline approach would ever become popular 
in C++.

See my response to Steven - probably my main issue is wanting 
some very different concept, dedicated stream/pipeline 
abstraction that would still be usable with all the same 
std.algorithm

> It seems to me, sometimes if I went by what this forum agrees 
> upon I'd write one thousand lines of code one day and remove it 
> the next.

Please don't take my rants in the NG as a serious call to action. 
I am simply sharing my concerns in a relevant topic - if there 
was anything pragmatical I could propose, I'd take it to the mail 
list instead or even right a DIP. To be honest, I'd even prefer 
if you ignored _any_ request/proposal which is not submitted as 
such. NG can't be taken as a base for reasoning.

>> Phobos indeed doesn't seem to make such priorities right now 
>> and that is
>> one of reasons I am growing increasingly unhappy with it.
>
> What steps do you think we could take with Phobos to make it 
> better without breaking backward compatibility?

Introducing `std2` package is technically not breaking backwards 
compatibility but I presume this is not what you have meant ;) I 
don't know - as I have already said, otherwise I'd actually taken 
some more constructive actions instead of throwing complaints.

If I'd have a say in designing brand new Phobos, it would be very 
different - async by default, with a strict separation of 
lightweight @nogc algorithm and API core (fitting even for 
embedded env) and all the feature rich additional modules built 
on top. This is not kind of stuff one simply "fixes" in existing 
mature library.

At the same time, I am not even sure if it is even important to 
fix. It is good enough for any kind of general purpose 
development, good for productivity. And bigger projects with hard 
performance concerns and maintenance costs tend to grow their own 
"standard" libraries anyway.