Skip to content

Language feature: turboball as postfix operator #2698

@swfsql

Description

@swfsql

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

This is a suggestion to the discussion at

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).

Activity

swfsql

swfsql commented on May 13, 2019

@swfsql
Author

I've published a crate for anyone interested in exploring this syntax: https://crates.io/crates/sonic_spin

added
A-operatorOperators related proposals.
A-syntaxSyntax related proposals & ideas
T-langRelevant to the language team, which will review and decide on the RFC.
on Nov 17, 2019
scottmcm

scottmcm commented on Nov 11, 2020

@scottmcm
Member

Hmm, if we had postfix match then

.pipe(|bar_0| bar(bar_0, 42))

would be

.match { bar_0 => bar(bar_0, 42) }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-operatorOperators related proposals.A-syntaxSyntax related proposals & ideasT-langRelevant to the language team, which will review and decide on the RFC.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @swfsql@jonas-schievink@scottmcm

        Issue actions

          Language feature: turboball as postfix operator · Issue #2698 · rust-lang/rfcs