[RFC] Add an operator for ranges to D. Pros and cons?

[Dejan Lekic]

bearophile wrote:

> Dejan Lekic:
> 
>> Dear D community, I do not know about You, but I certainly do
>> not like writing code like:
>>
>> inRange.fooRange(param).barRange.
>>   .bazRange(param1, param2).outRange;
> 
> I suggest to format it this way, it's more readable:
> 
> auto something = inRange
>                   .fooRange(param)
>                   .barRange()
>                   .bazRange(param1, param2)
>                   .outRange();
> 
> 
>> Therefore I would like to know what do you think about the idea
>> of having additional operator exclusively made for ranges? This
>> operator would make it obvious that data are "streamed" (lack
>> of better term) among ranges.
>>
>> The first name I could come up with was "opArrow" but "opData"
>> could also be okay, and operator would be either "~>" or "->".
>>
>> This would give us an obvious, unambiguous statement:
>>
>> Console.in ~> filter1(param) ~> fooRange ~> Console.out;
>> // Console is an imaginary class/struct
> 
> I think it doesn't give a significant improvement. But maybe
> there are more interesting use cases.
> 
> I'd like D ranges to support the "~" (using a template mixin to
> give them such operator), that acts like chain. So instead of
> writing:
> 
> range1.chain(range2)
> 
> You write:
> 
> range1 ~ range2
> 
> It's also nice to have lazy lists, maybe based on fibers, with
> few operators to concat them, etc.
> 
> Bye,
> bearophile

I already did try using the tilda operator for a while, then I realised that 
people are getting confused thinking the line is concatinating strings, then 
then realise those are ranges... That is exactly the reason why I asked the D 
community what they think about having a new operator only for ranges...

I also do what you suggest quite a lot. In fact I almost write it the same way 
you do in your example. But think about potential scenario when you give 
parameters as members of some structure:

auto something = inRange
                   .fooRange(someObject.someMember.membersMember)
                   .barRange(SomeClass.staticMember)
                   .bazRange(/* etc */)
                   .jarRange(param1, param2)
                   .outRange(/* etc */);

Moreover, what if developer does not add "Range" to the name (typical case)? 
Imagine confusion with such UFCS methods and properties... 

-- 
Dejan Lekic - http://dejan.lekic.org