std.range: Order of arguments unluckily chosen?

[Timon Gehr]

Michel Fortin wrote:
> 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/


I was about to propose the same. It also nicely disallows cases where UFCS is
actually quite nonsensical, like Eg. y.atan2(x);
But since it requires a language change, we'll be waiting a long time for it.
(Even though everyone on this newsgroup seems to be talking about UFCS a lot.)

How would the function make use of the parameter? I suggest that an explicit
"this" should be required. (making it just a specially named parameter) Also, it
would have to be discussed if structures and classes can define member functions
using this syntax. I suggest to disallow it for non-static methods.

Note: C# has a feature called "extension methods", that does basically the same in
C#, "this" is just a parameter type modifier. But it is less powerful than the
proposal, because it can be applied to the first parameter only.

I am a bit concerned about this though:

int foo(int a, int this, int c);

foo(1,2,3);
<=>
(2).foo(1,3); // somewhat strange

Is there any use case for that?


Timon