-
Notifications
You must be signed in to change notification settings - Fork 4
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
Explicit "unsafe" in session type language #80
Comments
Related to this issue, the function fn try_into_inner(self) -> Option<(Tx, Rx)> {
// only return `Some` if drop guard is a unique `Arc`
} Documentation should discourage the use of this function and refer to |
Some may object to calling any of this "unsafe" since it cannot result in memory unsafety. Alternate nomenclature: Presently, my favorite set of naming is |
Currently, if one needs to escape the session typing regimen temporarily, there is no way to do so while retaining the drop guards which are necessary to continue in
over
/split
/call
. Additionally, there is no marker in the type system to point at locations in a protocol where extra scrutiny is required due to departure from the listed session type.Both of these issues can be allayed by the introduction of:
Unsafe<P>
(only parameter is continuation, since its innards are opaque),Session!
macro keywordunsafe;
(no block, since its innards are opaque), andChan<S, Tx, Rx>
:In the above,
DropGuard<T>
is similar to the existing pattern in Dialectic of pairing aT
with anArc<Mutex<Result<T, IncompleteHalf<T>>>>
and aDrop
implementation that placesT
in the mutex. In the case ofDropGuard
, we don't need to worry about the case of an unfinished session, sinceUnsafe
doesn't specify what session completion means. Thus,DropGuard
should contain merely anArc<Mutex<Option<T>>>
. We can then implementDeref
andDerefMut
forDropGuard
, allowing it to be used however the underlyingTx
/Rx
can be—including as the transmitter/receiver for a newChan
. This last ability means thatUnsafe
can crucially be used to nest protocols with different ways of using the underlying transport: for instance, to use different encodings/framings for messages in different parts of a protocol, or to embed a multiplexed subprotocol in a larger protocol, per the multiplexing backend described in #79.The text was updated successfully, but these errors were encountered: