Description
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
- Simple postfix macros #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).