Skip to content

Commit ed172fe

Browse files
authored
PromiseTransmutable extension
#5 (comment)
1 parent bc1963f commit ed172fe

File tree

1 file changed

+35
-4
lines changed

1 file changed

+35
-4
lines changed

rfcs/0000-safe-transmute.md

Lines changed: 35 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -529,8 +529,9 @@ Why is this the case?
529529

530530
The type `<Src as PromiseTransmutableInto>::Archetype` exemplifies the furthest extreme of non-breaking changes that could be made to the layout of `Src` that could affect its use as a source type in transmutations. Conversely, `<Dst as PromiseTransmutableFrom>::Archetype` exemplifies the furthest extreme of non-breaking changes that could be made to the layout of `Dst` that could affect its use as a destination type in transmutations. If a transmutation between these extremities is valid, then so is `Src: TransmuteInto<Dst>`.
531531

532-
#### Common Use-Case: Promising a Fixed Layout
533-
To promise that type's layout is completely fixed, simply `derive` the `PromiseTransmutableFrom` and `PromiseTransmutableInto` traits:
532+
#### Common Use-Case: As-Stable-As-Possible
533+
[stability-common]: #common-use-case-as-stable-as-possible
534+
To promise that all transmutations which are currently safe for your type will remain so in the future, simply annotate your type with:
534535
```rust
535536
#[derive(PromiseTransmutableFrom, PromiseTransmutableInto)]
536537
#[repr(C)]
@@ -571,9 +572,10 @@ const _: () = {
571572
}
572573
};
573574
```
575+
Since deriving *both* of these traits together is, by far, the most common use-case, we [propose][extension-promisetransmutable-shorthand] `#[derive(PromiseTransmutable)]` as an ergonomic shortcut.
574576

575-
576-
#### Uncommon Use Case: Complex Stability Guarantees
577+
#### Uncommon Use-Case: Weak Stability Guarantees
578+
[stability-uncommon]: #uncommon-use-case-weak-stability-guarantees
577579

578580
If you are *most people* and want to declare your types as layout-stable, you should follow the advice in the previous sections. In doing so, you declare that you will *not* modify the layout of your type in virtually any way, except as a breaking change. If your type's fields have simple stability guarantees, this effects the strongest possible declaration of stability: it declares that *all* transmutations that are safe are *also* stable.
579581

@@ -1989,6 +1991,35 @@ The omission is intentional. The consequences of such an option are suprising in
19891991
# Future possibilities
19901992
[future-possibilities]: #future-possibilities
19911993

1994+
## Extension: `PromiseTransmutable` Shorthand
1995+
[extension-promisetransmutable-shorthand]: #extension-promisetransmutable-shorthand
1996+
1997+
We anticipate that *most* users will merely want to [promise][stability-common] that their types are as-stable-as-possible. To do so, this RFC proposes the shorthand:
1998+
```rust
1999+
#[derive(PromiseTransmutableFrom, PromiseTransmutableInto)]
2000+
#[repr(C)]
2001+
pub struct Foo(pub Bar, pub Baz);
2002+
```
2003+
As a shorthand, this is still rather long. For such users, the separability of `PromiseTransmutableFrom` and `PromiseTransmutableInto` is totally irrelevant. We therefore propose a `derive(PromiseTransmutable)` shorthand, such that this:
2004+
```rust
2005+
#[derive(PromiseTransmutable)]
2006+
#[repr(C)]
2007+
pub struct Foo(pub Bar, pub Baz);
2008+
```
2009+
...is equivalent to this:
2010+
```rust
2011+
#[derive(PromiseTransmutableFrom, PromiseTransmutableInto)]
2012+
#[repr(C)]
2013+
pub struct Foo(pub Bar, pub Baz);
2014+
```
2015+
2016+
However, we caution *against* adding a corresponding trait or trait alias; e.g.:
2017+
```rust
2018+
trait PromiseTransmutable = PromiseTransmutableFrom + PromiseTransmutableInto;
2019+
```
2020+
The vast majority of users will *only* confront the stability declaration traits in the context of deriving them; the *only* scenario in which end-users will refer to these traits in a type-context is the [rare use-case][stability-uncommon] of *manually* implementing them. For such users, the separability of `PromiseTransmutableFrom` and `PromiseTransmutableInto` *is* relevant. The availability of a `PromiseTransmutable` trait or trait alias in this scenario would be a distraction, since referring to it in a type-context is almost certainly a misstep.
2021+
2022+
We acknowledge that it is unusual for a `derive` macro to not create an item of the same name, but this weirdness is outweighed by the weirdness of the alternative: providing a trait for which there is almost no good use.
19922023

19932024
## Extension: Byte Transmutation Traits
19942025
[marker-traits]: #Extension-Byte-Transmutation-Traits

0 commit comments

Comments
 (0)