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.
