Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mailbox should be the first argument in spawn and spawn_link #62

Open
tqwewe opened this issue Aug 14, 2022 · 5 comments
Open

Mailbox should be the first argument in spawn and spawn_link #62

tqwewe opened this issue Aug 14, 2022 · 5 comments

Comments

@tqwewe
Copy link
Member

tqwewe commented Aug 14, 2022

The Mailbox prameter in the spawn and spawn_link functions is expected to be the last parameter.

I think it might make more sense for it to be first, since it's always required?
Similar to how typically optional/default arguments are placed last in many languages, similar to the type definition of Mailbox<T, S = Bincode>, with T being required, and S being optional.

I think a side effect of this, would be that the spawn! and spawn_link! macros could accept multiple captured variables. Currently they only support one, but it could be many:

spawn!(|mailbox: Mailbox<String>, cap1, cap2, cap3| { ... })

With mailbox being last, I don't think this is really possible.

It's a pretty minor change, and would be a breaking change sadly, but I thought I'd open an issue anyway.

@ianxek
Copy link

ianxek commented Aug 15, 2022

Yes, I stumbled upon the same problem, trying to pass cap1, cap2 etc. before mailbox. But why isn't it possible to define a macro that handles mailbox being last? And what about mixing captured variables, variables defined during invocation, and mailbox: in what order?

@tqwewe
Copy link
Member Author

tqwewe commented Aug 15, 2022

If you try this example (with mailbox last):

macro_rules! spawn {
    ( $( $captures:expr ),*, $mailbox:expr ) => {};
}

spawn!(1, 2, 3);

It has an error:

local ambiguity when calling macro spawn: multiple parsing options: built-in NTs expr ('mailbox') or expr ('captures').

But switching captures and mailbox around, it works just fine.
There may be a way to solve this while keeping mailbox last, but the most simplest solution I think is to just swap them.

@bkolobara
Copy link
Contributor

Sorry, I completely forgot to come back to this.

The reason why it's the last argument is to stay consistent with Process::spawn().

I'm not completely against changing this. Ideally, I would like Process::spawn to take a variable number of arguments, but this just can't be expressed because of limitations in Rust :(

@tqwewe
Copy link
Member Author

tqwewe commented Sep 6, 2022

Ideally, I would like Process::spawn to take a variable number of arguments, but this just can't be expressed because of limitations in Rust

Can we not do something similar to submillisecond, where we implement a trait for a function?

impl<M, A, B, C> SpawnFn<M, (A, B, C)> for fn(Mailbox<M>, A, B, C)
where
    M: Serialize,
    A: Serialize,
    B: Serialize,
    C: Serialize,
{ ... }

@bkolobara
Copy link
Contributor

Can we not do something similar to submillisecond, where we implement a trait for a function?

Not without forcing everyone to write spawn(my_func as fn(_, _, _, _)) (we do the this for users in the router! macro automatically)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants