std.range: Order of arguments unluckily chosen?

[so]

On Sun, 05 Jun 2011 02:25:46 +0300, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2011-06-04 18:55:54 -0400, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On 06/04/2011 03:11 PM, Timon Gehr wrote:
>>> I think the order should be swapped. It is also the way functional  
>>> language
>>> libraries handle it. It works better with currying too.
>>>  Any comments/arguments on why the current order is the right order?
>>  Well this hurts. With the same in mind as you, I initially defined  
>> take to take the number first. But OO people wanted to write  
>> array.take(3), so I changed the order. Don't forget that UFCS is still  
>> on the table.
>>  Impossible to please everybody!
>>  I don't know what to do to improve the situation.
>
> Perhaps like this:
>
> 	auto take(R)(uint count, R this) { ... }
>
> Note that the second parameters's name is "this", which would mean that  
> the second argument is the one that disappear using the member syntax.
>
> It can then be called this way:
>
> 	take(3, range);
>
> or this way:
>
> 	range.take(3);
>
> Having to specify explicitly whether a function is meant for  
> member-syntax this way would also fix a couple of issues regarding UFCS:  
> UFCS properties would be able to work correctly, and name clashes would  
> happen less often when using the member syntax.

Nice idea to make sense out of the UFCS, but i fail to realize the  
actually need for UFCS to begin with.
To me, the need to convert "take(3, range)" to "range.take(3)" is  
non-existent (and this wouldn't be the only reason i could come up with),  
probably i am missing something. And because everyone likes this, it must  
be something big :)