# \[Pitch\] Constrain implicit raw pointer conversion to bitwise-copyable values

**URL:** <https://forums.swift.org/t/pitch-constrain-implicit-raw-pointer-conversion-to-bitwise-copyable-values/63314>\
**Category:** Pitches\
**Created:** [February 23, 2023, 5:04pm UTC](https://forums.swift.org/t/pitch-constrain-implicit-raw-pointer-conversion-to-bitwise-copyable-values/63314 "2023-02-23T17:04:32Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [February 23, 2023, 9:44pm UTC](https://forums.swift.org/t/pitch-constrain-implicit-raw-pointer-conversion-to-bitwise-copyable-values/63314/6 "2023-02-23T21:44:20Z")

</div>

+1 to this proposal. AFAIK it solves everything we [discussed recently](https://forums.swift.org/t/strictvaluetype-protocol/63229), does this to a much greater level of detail and is backed with the implementation already, so well done.

> [@](#):
>
> A type that contains no class references is referred to as bitwise copyable, because copying its value is equivalent to calling `memcpy`

`memcpy` works at the byte level (i.e. it can't copy 7 bits of a byte without copying the 8th (memory I/O is done at a byte granularity)) and thus memcpy doesn't even talk about bits in its man page. However I agree that "BitwiseCopyable" is a good name to use here and not any worse than a potential "BytewiseCopyable" alternative.

> [@](#):
>
> To mitigate source breakage, conversion of generic types that conform to `FixedWidthInteger` will be allowed.

I guess Double could follow the suit.

What about the tuples? Will there be some automatic conformance that says: the tuple of "BitwiseCopyable" elements is "BitwiseCopyable" itself? Or will it be possible to manually conform a tuple class to "BitwiseCopyable" (provided its elements are "BitwiseCopyable")?

On a point of clarification, would the "BitwiseCopyable" applied to a struct mean what "POD" currently means? In other words will it follow (1) or (2) below?

> [@StrictValueType protocol](https://forums.swift.org/t/strictvaluetype-protocol/63229/12):
>
> 1. POD/PDS values (those can be recreated as "copies" from bits in a different process).
> 2. values that can be recreated as copies from bits in the same process only.
> 3. a value that can be recreated as a unique copy from bits in the same process (original value is destroyed). Attempt to create a second copy from the same bits should fail (somehow)_, or successfully create a new unique copy with the previously unique copy destroyed the moment the new unique copy is created (Edited)_.

On that front, could BitwiseCopyable be applied to a reference type? (obviously the one that doesn't contain reference fields in its payload). I guess – "no" and it is worth to mention it in the proposal (unless it is already mentioned and I just missed it).

---

_[View the full topic](https://forums.swift.org/t/pitch-constrain-implicit-raw-pointer-conversion-to-bitwise-copyable-values/63314)._