• Jonathan M Davis (26/26) Aug 15 2011 Okay. Currently take's arguments are range then number. As I understand ...
• so (12/52) Aug 15 2011 No please.

Jonathan M Davis <jmdavisProg gmx.com> writes:

Okay. Currently take's arguments are range then number. As I understand it, 
they were previously number and then range, but some folks complained about 
not being able to use arrays' member function call syntax that way, so it was 
changed to what it is now. The downside to that is that code becomes much 
harder to read when you chain functions. e.g.

auto r = find(take(map!(std.uni.toUpper)(range), 5)), "hello");

is harder to read than

auto r = find(take(5, map!(std.uni.toUpper)(range))), "hello");

And of course, it only gets worse the more functions you chain. It becomes 
very easy to lose which function the number actually goes with. So, what I'm 
wondering is whether it would be worthwhile defining take _both_ ways.

Take!R take(R)(R input, size_t n)

and

Take!R take(R)(size_t n, R input)

Normally, I wouldn't want to do that, since it's arguably pointless function 
duplication, but it would be totally unambiguous in this case, and it would 
allow you to have the member function call syntax if prefer that or to have 
the increased readibility if you want that. I _really_ prefer having the size 
first, because it makes the code more readible, so personally, I'd prefer to 
either change it back to the way that it was or do this, but I can understand 
people wanting to use the member function call syntax for arrays.

So, the question is whether this is at all a good idea. And if not, is there 
any kind of real support for changing it back to take the number first? If 
we're stuck with the way that it is, we're stuck with the way that it is, but 
IMHO the current situation with take is suboptimal.

- Jonathan M Davis

so <so so.so> writes:

On Tue, 16 Aug 2011 08:00:58 +0300, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 Okay. Currently take's arguments are range then number. As I understand  
 it,
 they were previously number and then range, but some folks complained  
 about
 not being able to use arrays' member function call syntax that way, so  
 it was
 changed to what it is now. The downside to that is that code becomes much
 harder to read when you chain functions. e.g.

 auto r = find(take(map!(std.uni.toUpper)(range), 5)), "hello");

 is harder to read than

 auto r = find(take(5, map!(std.uni.toUpper)(range))), "hello");

 And of course, it only gets worse the more functions you chain. It  
 becomes
 very easy to lose which function the number actually goes with. So, what  
 I'm
 wondering is whether it would be worthwhile defining take _both_ ways.

 Take!R take(R)(R input, size_t n)

 and

 Take!R take(R)(size_t n, R input)

No please.

 Normally, I wouldn't want to do that, since it's arguably pointless  
 function
 duplication, but it would be totally unambiguous in this case, and it  
 would
 allow you to have the member function call syntax if prefer that or to  
 have
 the increased readibility if you want that. I _really_ prefer having the  
 size
 first, because it makes the code more readible, so personally, I'd  
 prefer to
 either change it back to the way that it was or do this, but I can  
 understand
 people wanting to use the member function call syntax for arrays.

 So, the question is whether this is at all a good idea. And if not, is  
 there
 any kind of real support for changing it back to take the number first?  
 If
 we're stuck with the way that it is, we're stuck with the way that it  
 is, but
 IMHO the current situation with take is suboptimal.

 - Jonathan M Davis

AFAIK only sensible solution (as proposed) is improving UFCS. It is a  
complete solution, not a workaround.

void fun(A1, A2, <keyword> A3, A4) {}

fun(A1, A2, A3, A4);
A3.fun(A1, A2, A4);

And for take:
R take(size_t A1, <keyword> A2) {}

take(A1, A2);
A2.take(5)