Skip to content

Commit a70131c

Browse files
committed
Specify #[repr(transparent)]
1 parent 1f5d3a9 commit a70131c

File tree

1 file changed

+71
-0
lines changed

1 file changed

+71
-0
lines changed

text/0000-repr-transparent.md

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
- Feature Name: `repr_transparent`
2+
- Start Date: 2016-09-26
3+
- RFC PR: (leave this empty)
4+
- Rust Issue: (leave this empty)
5+
6+
# Summary
7+
[summary]: #summary
8+
9+
Extend the existing `#[repr]` attribute on newtypes with a `transparent` option
10+
specifying that the type representation is the representation of its only field.
11+
12+
# Motivation
13+
[motivation]: #motivation
14+
15+
On some ABIs, structures with one field aren't handled the same way as values of
16+
the same type as the single field. For example on ARM64, functions returning
17+
a structure with a single `f64` field return nothing and take a pointer to be
18+
filled with the return value, whereas functions returning a `f64` return the
19+
floating-point number directly.
20+
21+
# Detailed design
22+
[design]: #detailed-design
23+
24+
The `#[repr]` attribute on newtypess will be extended to include a form such as:
25+
26+
```rust
27+
#[repr(transparent)]
28+
struct TransparentNewtype(f64);
29+
```
30+
31+
This structure will still have the same representation as a raw `f64` value.
32+
33+
Syntactically, the `repr` meta list will be extended to accept a meta item
34+
with the name "transparent". This attribute can be placed only on newtypes,
35+
which means structures (and structure tuples) with a single field.
36+
37+
Some examples of `#[repr(transparent)]` are:
38+
39+
```rust
40+
// Transparent struct tuple.
41+
#[repr(transparent)]
42+
struct TransparentStructTuple(i32);
43+
44+
// Transparent structure.
45+
#[repr(transparent)]
46+
struct TransparentStructure { only_field: f64 }
47+
```
48+
49+
This new representation is mostly useful when the structure it is put on must be
50+
used in FFI context as a wrapper to the underlying type without actually being
51+
affected by any ABI semantics.
52+
53+
It is also useful for `AtomicUsize`-like types, which [RFC 1649] states should
54+
have the same representation as their underlying types.
55+
56+
[RFC 1649]: https://github.com/rust-lang/rfcs/pull/1649
57+
58+
# Drawbacks
59+
[drawbacks]: #drawbacks
60+
61+
None.
62+
63+
# Alternatives
64+
[alternatives]: #alternatives
65+
66+
None.
67+
68+
# Unresolved questions
69+
[unresolved]: #unresolved-questions
70+
71+
None.

0 commit comments

Comments
 (0)