On 9/25/16 4:05 PM, pineapple wrote:
On Sunday, 25 September 2016 at 13:57:04 UTC, Jonathan M Davis wrote:
The way it works now is how it's always worked with dynamic arrays and
ranges in D. If you're trying do anything else, you're just going to
run into problems in the long run - particularly when interacting with
code written by anyone else. So, while you're obviously free to do
whatever you want with your own code, don't expect Phobos or D code in
general to change how ranges fundamentally work.
That change is exactly what I'm arguing against - that the front,
popFront, etc. functions defined for dynamic arrays in phobos should not
be adopted by the core language.
On Thursday, 22 September 2016 at 12:51:59 UTC, Andrei Alexandrescu wrote:
Would make sense to move those few primitives to object.d. I've been
thinking of that a long time ago but back then there was a vague
stance that object.d shouldn't contain templates. Since then that has
changed. -- Andrei
Please do not do this - there ways to handle ranges other than the
approach phobos has taken. That's it, that's the point I'm trying to make.
We learned with time that any step we're trying to take toward progress
in a matter of design (i.e. no mechanical rules, reasonable people may
disagree), a faction will strongly oppose it. I speculate this has to do
with our community being self-selected as opinionated folks who don't do
well with conventional wisdom.
At the same time, we can't let this gridlock development of D. We must
go with what we think is good.
It seems you want to define ranges with similar syntax but subtle
semantic differences, e.g. r.front and r[0] to mean different things.
The entire Phobos is designed under the assumptions that ranges work a
specific way, so in order to design a different mechanism you may want
to use different syntactic interfaces.
Andrei
