Argumnentation against external function operator overloading is unconvincing

[Andrei Alexandrescu via Digitalmars-d]

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