Send/Sync -ability over functions

[tower120]

"Data-race safety" is mentioned as one of the goals in language design.
It looks like you didn't touched that part yet, so there is plenty of space for design choices.

Rust use Send Sync traits over data, to prevent non-thread-safe friendly structures from crossing "thread barrier" (being moved to another thread, or being referenced from the other thread). Looks like that approach gained some traction...
"Sometimes" though, from practical perspective, this approach feels ... too coarse. For example struct may have a single non-Send/Sync field that makes whole struct unusable in MT context:

struct S{
   x: i32,
   y: i32,
   non_sync: NonSync
}

Yet, that field may be actually never touched from the other thread. [Looks like Rust's common solution for this is struct-slicing]

What if apply Send/Sync attribute to member functions instead? By default function is Send+Sync, if function call non-Send function inside - it's Send attribute removed. The same for Sync. Attributes may be manually re-attached to function (ala unsafe impl Send in Rust) by user. For objects that crossed Send/Sync barrier, only member-functions with Send/Sync attributes can be called.
All forms of access to object can be represented as function calls... So, if needed, Rust's behavior could be mimicked with this approach too.

If struct have some generic argument (like for example Vec) - it's functions attributes will automatically align with it's generic type. For example Vec::clone() will become non-Send if T::clone is non-Send, since inside it clone it's elements. Yet Vec still remain passable to another thread, where at the very least len() remains callable.

Modern IDEs can easily show deducted by compiler Send Sync attributes for each function.

P.S. I'm not sure this is the right place to discuss, and in case this was proposed or discussed somewhere else - my apologies in advance.

[danakj]

For objects that crossed Send/Sync barrier, only member-functions with Send/Sync attributes can be called.

I think this is an understated part of this strategy. A function only has types as inputs, so it can't know if something was passed over a thread previously.

One way I could see to make this work would be for any call to a non-send/sync method would have to be bubbled out of a function in its signature so that it could make its way up the stack to where a thread spawn/message passing, so that it can see that there's some non-send/sync use of some field in some structure that is accessible to the object being passed across threads. This would be rather noisy though.

[tower120]

What if mark every object that is passed to a thread as Sended? Sended object stripped of all members without Send attribute.

struct spsc<T>{
   queue: Vec<Sended<T>>
}
fn push_message(&mut self, value: T){
   // This is spsc implementation obligation to wrap anything that pass thread barrier into Sended.
  self.queue.push(Sended(value));
}

Well maybe not exactly like that. But the idea is to let compiler statically know that we want type to be altered in that way.

[danakj]

This would "colour" functions as being working with objects that were sent over a thread or not, reducing the reusability of code. And the Sended would need to somehow apply transitively to types reachable through the Sended type, such as fields of classes. As soon as you go through a pointer, you'd lose the additional Sended type. I don't feel confident in doing this through the type as such.

[tower120]

This would "colour" functions as being working with objects that were sent over a thread or not, reducing the reusability of code.

Well... That's true. But it's not like async/normal, its more like mut/const. Send-friendly function can be used with non-Sended objects too. And functions are Send by default, and becoming non-Send when you call non-Send function inside. So I assume most of the general code would be Send by default.

And the Sended would need to somehow apply transitively to types reachable through the Sended type, such as fields of classes.

Doesn't recursively applying Sended rules to object fields is not enough? (The same as with "constness")

As soon as you go through a pointer, you'd lose the additional Sended type.

How exactly "go through a pointer"? To void* and back?

---

I thought of a Sended more as a "type modifier", or as "special tag type" in Rust world.

The problem I see (both as type and as modifier) is that as a generic argument, they can't be mixed:

struct S<T>{
    v: Vec<T>
}

In this way you couldn't mix Sended and non-Sended T... But some kind of runtime wrapper could be made, that will throw error/panic - if non-send function called for Sended T. Or wrapper that remove all but Send functions (single check on wrapper construction):

struct S<T>{
    v: Vec<SendOnly<T>>   // only Send functions available. Constructible from both Sended and non-Sended T.
}