Language feature: turboball as postfix operator

Have the ::() ( turboball / rotating-arm / sonic spin ) to be a general postfix operator.

This is a suggestion to the discussion at

• https://internals.rust-lang.org/t/idea-universal-pipelining-a-k-a-making-await-generic/9973
• https://github.com/rust-lang/rfcs/pull/2442

and the proposed syntax is similar to turbofish but it doesn't collide with field access nor namespaces nor turbofish and it does not include new symbols.

for example, have..

a::(match) {
    // ..
}

..be equivalent to..

match a {
    // ..
}

---

and then possibly deal with macros as well:

have..

("{}", 1)::(println!);

..be equivalent to..

println!("{}", 1);

---

So applying this to the async and postfix situations,
If await is a "await prefix" (let x = await thing;), it's turboball would be let x = thing::(await);
If it's macro-like (let x = await!(thing);), it's turboball would be let x = (thing)::(await!).

note: as macro tokens would still require surroundings ((), [], {}), then macro cascading, if possible, would still require russian-dolling..

(
    (
        (res_res_res)::(try!)
    )::(try!)
)::(try!)

..unless you would always insert surrounding parenthesis - but this could interfere with other stuff, idk - or if you would treat unit-tuple (or "empty" as a sugar to the unit-tuple) as parenthesis surrounding insertion, something like..

res_res_res
    ::(())::(try!)
    ::(())::(try!)
    ::(())::(try!)

..and/or..

res_res_res
    ::()::(try!)
    ::()::(try!)
    ::()::(try!)

..then I guess cascading macros would work.

---

I don't know if every expression "modifier"/variant should be included (or if this makes sense).

For example..

object
    .a()
    .b()
    .c()
    ::(&)

..may be equivalent to..

&object
    .a()
    .b()
    .c()

or even, if..

result::()::(try!)

..were equivalent to..

try!(result)

..then the ExprTry (result?) wouldn't be necessary.

Except that as a ExprTry structure, it still holds the "expression information" (see <ExprTry>::expr field) and not only "token stream information" (as normal macros do - see <ExprMacro>::mac.tts field). So ::(try!) couldn't really replace ExprTry structure (and it's inner information).

---

About calling functions that require multiple parameters, the linked discussion suggests using clojures for that. If not by this, I'd personally prefer inserting the parameters into a tuple and then calling a loosened wrapper of the desired function - or use some mapping (like a loosening map) to destructure the input and forward to the normal desired function.

So the example foo(24, bar(baz(data), 42)) would be..

baz(data)
    .pipe(|bar_0| bar(bar_0, 42))
    .pipe(|foo_1|, foo(24, foo_1))

..and would not require turboball (like what was suggested by CAD97).

Start by reading the linked internals discussion and RFC 2442 pull request, then compare the proposed postfix syntax and its possible interactions with expressions, macros, and async usage. Done would require a settled language design and an accepted RFC, rather than an isolated code change.