std.range: Order of arguments unluckily chosen?

[Michel Fortin]

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.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/