Idea: |> operator for postfix calls to macros and free functions

[shingtaklam1324]

I think that it should be a simple syntactic sugar, which is expanded at the same time as macros, so a |> f(b, c) just expands to f(a, b, c), so the evaluation order is a then b then c, or whatever the Rust evaluation order is. If we decide to have it be an infix function, then it won’t make much sense without partial application like F#, but UMCS would probably be the better solution

[tmccombs]

@JustAPerson

Am I wrong that this pipeforward operator could subsume both the functionality of (untyped) postfix macros and the unified method call syntax? This seems like a powerful, orthogonal feature. I strongly prefer to changing method resolution

Yes, exactly!

I’d prefer -> to |> because it’s easier to type, but it might confuse C/C++ programmers. Perhaps .>, easy to type, still looks like a method, and has a visual cue of forwarding the lhs.

I don’t like “->” because that symbol has a completely unrelated use in function signatures.

@skysch

How would this be expected to handle evaluation order?

I think it would probably be best to desugar to something equivalent to:

let __temp__ = a;
f(__temp__, b, c)

so that it avoid weirdness with unspecified behavior for evaluation of arguments (if that is still unspecified, I don’t know if it is), and prevents “garden path sentences” with macros.

My general opinion on the whole matter is that I’d rather have a real currying mechanism instead, but to be honest, I haven’t thought it through much.

that wouldn’t work for macros

[Centril]

This seems like a powerful, orthogonal feature.

I don’t think it is orthogonal; you can already use normal application, so there’s nothing you can’t already do; all that changes is the style really.

I think it would probably be best to desugar to something equivalent to:

I’d use a match instead since it is the equivalent to let x = expr in x in functional languages and interacts better with temporaries:

match a {
    __temp__ => f(__temp__, b, c)
}

[JustAPerson]

I don’t think it is orthogonal; you can already use normal application, so there’s nothing you can’t already do; all that changes is the style really.

That’s true of both UMCS and postfix macros. However, postfix macros may be a special case of UMCS, but I strongly dislike further complicating implicit method resolution. This explicit syntax, very simple syntax enabling both features is great.

I’d use a match instead since it is the equivalent to let x = expr in x in functional languages and interacts better with temporaries:

Wait is that actually different than just wrapping the let statement inside a new scope block?

[zackw]

Two thoughts:

1. A feature like this could be really handy in conjunction with pipeline-structured data transformation libraries. An interesting model to look at is dplyr — I don’t think that could be exactly replicated in Rust, since it makes very heavy use of R’s lazy argument evaluation and arbitrary keyword arguments, but it should give you a whole class of use cases to think about, at least. (I regret to say I don’t know what similar things Rust might already have.)

2. If we’re going to have this feature, we also need to have backwards assignment/let-binding. What do I mean by that? Well, if you’re crunching data with dplyr and you don’t know R has backwards assignment, you find yourself writing things like

   crunched <- (raw %>% select(...) %>% filter(...) %>% group_by (...)
                %>% summarise(...))
   

   But it’s more readable to write it like this:

   raw %>% select(...) %>% filter(...)
       %>% group_by (...) %>% summarise(...))
       ->  crunched
   

   like how you would do it in shell with | and >. Translated to the language of this proposal, that would mean being able to write

   let raw |> select(...) |> filter(...) 
           |> group_by(...) |> summarise(...)
           |> crunched;
   

   and have that introduce crunched, not raw, as the new binding. If you hate that, that probably means you’re going to hate pipeline operators.

3. Wouldn’t it be nice to be able to go the other way, too, sometimes?

   let crunched <| summarise(...) <| group_by(...)
                <| filter(...) <| select(...) 
                <| raw;

[scottmcm]

that would mean being able to write

I doubt it would be exactly like that, because let wants to be able to parse a pattern after itself, and like that it was an expression there.

Though I suppose with the proposed is operator, you could do that as

raw
    |> select(...) 
    |> filter(...) 
    |> group_by(...) 
    |> summarise(...)
    is crunched;

using an irrefutable pattern to introduce a binding.

(Said without taking a position on whether this would be something I’d like.)

[Centril]

However, postfix macros may be a special case of UMCS, but I strongly dislike further complicating implicit method resolution. This explicit syntax, very simple syntax enabling both features is great.

Well, strong dislike (why btw?) does not change the non-orthogonality.

The question with |> becomes: “Well, can I use it for normal methods as well?”. If the question for that is “yes”, then you’ve re-invented method syntax all over again with just two sigils instead of one. If no, then it is strictly less powerful and general.

Wait is that actually different than just wrapping the let statement inside a new scope block?

See eddyb’s comment here.

[MajorBreakfast]

There is a fair amount of pushback on both of these proposal because they allow things that look like method calls that aren’t method calls.

I’m in this camp. Today, a method is either an inherent method or from one of the type’s traits. Therefore the method can be considered to “belong” to the type. I think this mental model is very valuable when thinking about the code and it also works well for documentation. I like that your proposal keeps this mental model intact.

Perhaps .> , easy to type, still looks like a method, and has a visual cue of forwarding the lhs.

That’d be a good alternative. Here’s how the code would look like:

let crunched = raw.>select(...)
                  .>filter(...) 
                  .>group_by(...)
                  .>summarise(...);

Is it better? I think that it combines better with normal method calls:

let x = raw.method1().method2()|>func().method3();

let x = raw.method1().method2().>func().method3();

---

@zackw I think we should stick with the simple let ident = ... syntax. A special let syntax is IMO not appropriate because it probably won’t be used often enough to warrant it. Same goes for <|. Nice idea, but I think I wouldn’t have a use for it if it existed. That’s just my 0.02€. But I think it’s good that you’ve mentioned it as a possibility.

[vorner]

From the two mentioned, I think .> fits better (I don’t know if I like the idea of another operator, but this one looks more „Rusty“). | evokes alternative/binary or association.

I just wonder, is introducing such operator backwards compatible? It was two tokens before, would be one now and some macro might have accepted the sequence before.

[MajorBreakfast]

I just wonder, is introducing such operator backwards compatible?

I doubt that it would break anything. However, it’s possible to introduce it just as a part of Rust 2018: Rust 2018 operators thread

Another advantage of .> is also that it looks like as if it performs auto-deref. (Which I think it should perform)

[HadrienG]

Fuel for the syntax bikeshed: we already have two arrow operators in Rust, -> and =>, is it really wise to introduce yet another operator which looks like an arrow?

[MajorBreakfast]

@HadrienG ^^’ I’ve searched a lot on my keyboard for alternative appropriate characters. It’s tough!

I think .> looks quite good. I can’t come up with anything better.

[kennytm]

.> is ambiguous.

    fn foo(a: f32) -> f32 { a }

    let g = 2.>foo(1.);
    assert!(g);

[MajorBreakfast]

@kennytm Indeed. It compiles… (playground link)

[Tom-Phinney]

.> is ambiguous.

Just one more footgun caused by Rust’s not requiring fp<N> literals to have a digit on both sides of the decimal point when a decimal point is present. That decision was certainly one of the class of “let’s save typing one character, and the hell with the visual ambiguity” (e.g., vs a method call).

[petrochenkov]

not requiring fp<N> literals to have a digit on both sides of the decimal point when a decimal point is present.

I was recently surprised by things like 1. being accepted as float literals, because I have some memories about Rust not accepting them as a FP literals somewhere in 2014, but https://rust.godbolt.org says that 1.0 already accepts it.
I may be wrong and can’t check right now, so perhaps those are false memories, but perhaps someone actually though it was a good idea to support this and intentionally changed the behavior right before 1.0.

[tmccombs]

The question with |> becomes: “Well, can I use it for normal methods as well?”. If the question for that is “yes”, then you’ve re-invented method syntax all over again with just two sigils instead of one. If no, then it is strictly less powerful and general.

I think the answer to that is “yes”, but it has to be called as a function with UFCS. For example:

a |> MyStruct::my_method(b,c)

a |>my_method(b,c) would not be valid, unless there is a free function called “my_method” in scope.

which brings up another point I forgot to mention. I think the call position should specifically allow using full paths, not just the names of the functions (or macros).

[zackw]

let crunched = raw.>select(...)
                  .>filter(...)
                  .>group_by(...)
                  .>summarise(...);

Your writing this with minimal spacing around the .> operator, and all the talk of method syntax, concerns me, because it makes me think you’re thinking of this as a variant of the . operator, which is very wrong for the data-crunching use cases I care about. Data-crunching pipelines want a lowest-precedence pipeline operator, one that should be thought of as an alternative to assigning intermediate results to a temporary variable; not a high-precedence operator that is thought of as an alternative call syntax. (I don’t know what use cases you have in mind.)

For instance, in data-crunching contexts it may make sense to write a bare lambda as an element in one of these pipelines,

let alpha = 0.1; 
let crunched = raw .> |m| m * alpha .> filter(|e| e > 0.01) .> ...;

where the second .> operator and everything that follows should not be part of the lambda expression.

(Apart from this I am indifferent between |> and .>.)

[MajorBreakfast]

@zackw Good that you bring that up. @tmccombs’s proposal proposes a call style similar to method calls, but leaves the . method call syntax itself as it works today. Consequently similar precedence as . is intended. |> suggests low precedence, doesn’t it? That’s unintuitive if it actually isn’t intended to be low precedence.

Your use case can be implemented with an iterator and functional programming. Or, if your dataset is large using a parallel iterator from rayon. This syntax (with precedence similar to .) is intended to be quite useful for iterators. @Centril came up with the whole controversial idea about changing the method call syntax because it would be useful for crates like itertools in this post (I think that’s where the idea first popped up).

[Centril]

Regarding:

let crunched = raw .> |m| m * alpha .> filter(|e| e > 0.01) .> ...;

Haskell has such an operator & (infixl 1, defined in Data.Function) such that you can write:

expr & \a -> a + 1 & \a -> a + 1

However, I don’t find that it is used often, partly because it is hard to tell from the operator alone where the lambda ends. I think .> in this example suffers the same problem.

@Centril came up with the whole controversial idea about changing the method call syntax because it would be useful for crates like itertools in this post (I think that’s where the idea first popped up).

My proposal can be decomposed into two independent parts:

1. allow method syntax for free functions and associated functions.
2. allow paths in method syntax, i.e foo.Arc::clone() etc.

They interact well with each other, but they are orthogonal.

Correct me if I am wrong, but I think what is controversial is 1. but not 2.

I’m in this camp. Today, a method is either an inherent method or from one of the type’s traits. Therefore the method can be considered to “belong” to the type. I think this mental model is very valuable when thinking about the code and it also works well for documentation.

As I elaborated in the post you linked to, UMCS can be made to work well in documentation by listing relevant free functions that take the type as its first argument (or a reference to it…) at the type. A more general solution is to list all functions that mention the type in some page easily reachable from the type’s documentation. This is sorely needed today anyways in my experience.

Associated functions of a trait with no type parameters can’t be called with method syntax, however, they do “belong” to the type. I think most existing free functions also naturally bias towards one type as a receiver, or can be made to do when encoding the function. “Belonging” is too fuzzy a notion to have such rigid rules as we have right now. I also don’t think the mental model of belonging goes away when letting free functions be called as methods. I know this, because when writing in Haskell, there are only free functions, but yet, I do think about which type to put first and what function belongs to what type all the time.