Auto-currying in Rust

[Drup]

What you really want here is labels.

How to do labels and how to do wildcards/partial application are slightly orthogonal decisions. The first help the later, but can be designed separately. Of course the two should be compatible.

Also, not sure why you want => instead of the simpler and clearer =.

[dobkeratops]

addNewControl(“New”, 50, 20, 100, 50); What does that mean? Types don’t help, it’s just &str, int, int, int, int

agree that the named arguments are a nice solution here (which is why i like the python idea, you get the ability to annotate with names routinely)… … but with the C++ overloading, you can “say it with types”. How about…

addNewControl(“New”, Point2d(50,20), Size2d(100,50))

‘addNewControl’ could have all sorts of overloads, - e.g. omit the ‘size’, and you expect it to figure it out itself. Omit position, and you expect it to place somewhere sensible in the parent window.

Its funny how divisive this is. I’ve seen people argue against keyword args claiming that leveraging types is superior. (You’re creating more semantics the compiler understands) - but I don’t see them as mutually exclusive. I’d like both

Also, not sure why you want => instead of the simpler and clearer =.

that doesn’t fit in rusts’ grammar already; = can be used within expressions. (but it returns () unlike c++… not sure of the use)

[iopq]

You’re right, they’re orthogonal, but I like my syntax. I think I’ll write up an RFC for just currying. Or is there one already?

[iopq]

addNewControl("New", Point2d(50,20), Size2d(100,50))

This is OK, but you still have to remember that’s it’s title, position, size

If you write addNewControl(Point2d(50,20), "New", Size2d(100,50)) it won’t compile, but with keyword args like

addNewControl(position => Point2d(50,20), title => "New", size => Size2d(100,50))

there is no problem

[nmbooker]

Apologies if I’m late to the game here, but…

Scala has a solution, whereby you chain parantheses:

def modN(n: Int)(x: Int) = ((x % n) == 0)

In Rust it might look something like:

fn map(f)(xs) { blah }

With that syntax, each grouping of parameters in () could contain its own mix of optional, keyword and positional arguments.

The syntax also maps neatly onto how you’d then expect to call the function.

[xcv]

I believe I’m also a bit late, but I’m glad that this thread is still alive.

I just wanted to say that I really like @Drup’s idea about wildcards/placeholders foo(_, 2, _, 3) for a few reasons:

• The original function doesn’t need to be modified in order to allow this
• As he suggests, it could also be used with operators and I believe that more complex expressions too, although I’m not sure to what degree it could be nested without ambiguity (for example, in _ + _.f(1, _) is the third “_” the identity function or the third parameter of the entire expression?)
• There’s no syntactic noise at all

I have one doubt though. What if the arguments aren’t exactly in that order? Could it be possible to use ordered placeholders to get something like $2.f($1)? I guess that repeating the dollar or whatever character is prefered could be used to escape nested expressions and avoid the ambiguity problem I mentioned in the second bullet: $1 + $2.f(1, $$1). I’m not sure that this fixes all the cases, though:

Perhaps it could be resolved by the type checker or should nested placeholders be forbidden? They don’t seem to be necessary at all.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.