Send ident conflict

[khionu]

I just hit a problem where I needed to use the std trait Send. A type alias does solve this, however I think this issue might be prevalent enough where it might be best to rename par's Send, and Recv to match.

Some ideas:

• Tx/Rx
• In/Out
• Give/Recv

My preference would be on Tx/Rx, since those have the same meaning as Send/Recv, and Give is a bit passive.

[faiface]

The way I solve this in the library is I use marker::Send for the standard trait. When designing the library, I was considering naming it differently, including Give, but nothing evoked the right meaning as much as Send, plus it's consistent with academic literature. I found using marker::Send for the trait to be a better compromise.

[khionu]

Maybe Sender/Receiver then, in line with channel terminology?

[khionu]

To elaborate, from the perspective of people whose choice of tools start with Rust, when they pick up Par, I would imagine them to expect Par to not conflict with std types. There's a hierarchy, in a sense, where conflicts with a tool are the responsibility of the tool that depends on the first. The std is here first, even more so here because Send is part of the prelude.

[faiface]

Sender/Receiver have the downside of being nouns instead of verbs, which imho would make the session types harder to intuitively understand, since they describe a sequence of operations.

The hierarchy argument makes sense, and I'd be up for changing the names if a good alternative is found. Unfortunately, all alternatives I've seen or considered seemed worse than the marker::Send compromise.

[Papierkorb]

Maybe a dumb idea, but what about Put / Pull? They're verbs and don't conflict. However, their naming is out of the ordinary, Sender / Receiver is the best in that regard if you want to solve the naming conflict.

My 2c: Send shouldn't be used as public name of a trait, as every rust developer will think of marker::Send. On the other hand, the user can also write par::Send instead to solve this issue. That's what I do, as I don't like having to name my stuff FooClient when Rust already offers an adequate unique naming scheme: foo::Client.

[dlom]

Pick your favorite:

use par::exchange::Send as Tx;
use par::exchange::Recv as Rx;

use par::exchange::Send as In;
use par::exchange::Recv as Out;

use par::exchange::Send as Give;
use par::exchange::Recv as Take;

use par::exchange::Send as Put;
use par::exchange::Recv as Pull;

[faiface]

use par::exchange::Send as Split;
use par::exchange::Recv as Join;

This also works.

In general, I'm very conflicted here. I understand that Send being a built-in Rust trait is not a small deal, conflicting with the type name par::exchange::Send, on the other hand, no other name seems suggestive enough of the function as Send...

One improvement I could make is to re-export Send and Recv in par, so that instead of par::exchange::Send or exchange::Send, one can write par::Send as a means of disambiguation.

I'm definitely open to more input or persuation.

[simonsan]

I find Tx/Rx, Push/Pull, and Emit/Consume really strong contenders. An option would be to threat the Send/Recv as internals and rexport them as e.g. Emit/Consume, so internally they make sense to you as a library author, and externally people don't have conflicts with std lib.