[BitwiseCopyable] Pitch. #2314

nate-chandler · 2024-02-09T22:42:53Z

A new marker protocol to identify types that can be trivially copied, moved, and destroyed.

Types exported from modules built with library evolution may be trivial during one build and subsequently cease to be trivial. That means the compiler must not infer the conformance for types exported from resilient modules. To avoid dialecticization based on whether a module is built in that way, require the annotation for all exported types.

Overload existing public stdlib functions on a BitwiseCopyable constraint to allow for ideal code generation for conforming types.

allevato

Hi all! I'll be review managing this proposal. I've left some comments based on our discussion in the language steering group.

allevato · 2024-02-29T20:58:06Z

proposals/nnnn-bitwise-copyable.md

+
+### Inference for types in evolving libraries
+
+This does not apply to public (or `@usableFromInline`) types defined within a module built with library evolution.


I took a glance at some of the recent PR history for the implementation, and it looks like this may be no longer accurate? If I'm understanding the implementation, the logic appears to have been updated such that BitwiseCopyable is only inferred for internal/fileprivate/private types, and not inferred for public/package types, regardless of library evolution mode. Is that correct, and if so, should this text be updated to match?

I think it would be good to call out explicitly the public/package vs. internal/fileprivate/private boundary here. Before package was added, declarations in Swift were often thought of in terms of "public, and everything else". Now that has shifted to "outside the module, and inside the module", and that's a shift we as a community need to better internalize (no pun intended). This is the first proposal of a few that deal with layout constraints and/or protocol synthesis where the same boundary will likely hold.

Rewrote this section in terms of "exported" types.

allevato · 2024-02-29T21:02:45Z

proposals/nnnn-bitwise-copyable.md

+
+For an exhaustive list, see the [appendix](#all-stdlib-conformers).
+
+### Additional BitwiseCopyable types


During discussion, a couple other cases came up that we think would be worth calling out explicitly:

Do raw-value enums get BitwiseCopyable inferred if its raw value type is BitwiseCopyable? I think there are a couple possible answers here: either "yes", if it would be inferred for the same enum without raw values or associated values since it's a simple ordinal, or "no" if it wouldn't also be inferred for that case. (That is, having a raw value doesn't affect the Swift layout of the enum, so there should be no difference in BitwiseCopyable inference from the non-raw-value case.)

Do imported C structs get BitwiseCopyable? If not, is there a way to add it (either retroactively, or via API Notes or __swift_attr__ in the header)?

Added a footnote for raw-value enums. Inference is based on the enum itself, not the RawValue type witness of its synthesized RawRepresentable conformance.

Added a section on imported C and C++ types. Conformance is inferred unless the fields are not representable in Swift (or in the C++ case if the type is non-trivial). Conformance can be forced even when not inferred via __attribute__((__swift_attr__("_BitwiseCopyable"))).

allevato · 2024-02-29T21:07:39Z

proposals/nnnn-bitwise-copyable.md

+
+The following protocols in the standard library will gain the `BitwiseCopyable` constraint:
+
+- `FixedWidthInteger`


The language steering group discussed these proposed conformances and we feel that FixedWidthInteger shouldn't be in this list. While the concrete types in stdlib that conform to it are certainly bitwise copyable, there are no semantic requirements of the protocol itself that require bitwise copyability.

The summary of FixedWidthInteger from the documentation is "An integer type that uses a fixed size for every instance"; while it's unlikely, an implementation could do something a bit tortured like store a pointer to heap storage that contains the actual value. It was felt that the term "fixed width" here refers to the range of values it can represent, rather than the internal representation.

Would you agree/disagree with that?

I would defer to @stephentyrone on this. It doesn't seem to make a practical difference, since we're explicitly notating every existing fixed-width integer type.

This remains unchanged for now, pending comment.

@stephentyrone Can you comment quickly on this, please?

What Tony said. Every FixedWidthInteger type in the stdlib is bitwise copyable, but it is technically possible for someone to implement a fixed-width integer type that is not.

allevato · 2024-02-29T21:07:52Z

proposals/nnnn-bitwise-copyable.md

+  - `UInt8.Words`, `UInt16.Words`, `UInt32.Words`, `UInt64.Words`, `UInt.Words`
+  - `Int8.Words`, `Int16.Words`, `Int32.Words`, `Int64.Words`, `Int.Words`
+- The fixed-precision floating-point types:
+  - `Float`, `Double`, `Float80`


Can you add Float16 here as well?

allevato · 2024-02-29T21:15:36Z

proposals/nnnn-bitwise-copyable.md

+  - `UnsafeBufferPointer.Iterator`, `UnsafeRawBufferPointer.Iterator`, `EmptyCollection.Iterator`
+  - `String.Index`, `CollectionDifference.Index`
+- Some types related to unicode
+  - `Unicode`


We considered some of the uninhabited types here and we feel that we need to be more selective about which get the conformance, even though they're trivially bitwise copyable by virtue of being uninhabited and thus zero-sized. Rather than looking at just the size of the type, should we consider intent—as in, would a user reasonably write a generic algorithm constrained by BitwiseCopyable that might involve one of these types?

We decided that the answer is probably no for Unicode, MemoryLayout, and CommandLine, as those are purely namespaces for other declarations. But on the flipside, the answer is probably yes for Never and SystemRandomNumberGenerator; Never does occur in generic contexts and we have precedence for adding other conformances to it for that purpose. Likewise, despite being zero-size, users do create values of SystemRandomNumberGenerator so the conformance makes sense there.

Updated the implementation and proposal accordingly. And added a few words to describe the inference suppression mechanism.

Per LWG feedback, these three conformances don't make sense.

Its omission was an oversight.

nate-chandler · 2024-03-05T00:58:18Z

Thanks for sharing the feedback @allevato. There should be an updated draft to address these points in the next day or so.

Clarified that it depends on the actual enum, not the `RawValue` type witness of the synthesized `RawRepresentable` conformance.

benrimmington · 2024-03-06T19:14:40Z

proposals/nnnn-bitwise-copyable.md

+The following protocols in the standard library will gain the `BitwiseCopyable` constraint:
+
+- `_Pointer`
+- `SIMDStorage`, `SIMDScalar`, `SIMD`


BitwiseCopyable has been removed from FixedWidthInteger.
Should it also be removed from the SIMD protocols?

SE-0229:

This is the bare minimum functionality upon which everything else is built; the expectation is that types conforming to this protocol will wrap LLVM Builtin vector types, but this is not necessary. Users can conform types to this protocol with any backing storage that can provide the necessary operations, which allows them to benefit from the semantics (and many operations will be autovectorized by the compiler in most cases, even without explicit vector types as storage).

When we discussed those, there was a sense that the SIMD protocols were less likely to be used in a way that wasn't BitwiseCopyable than FixedWidthInteger, though it's kind of a fine line.

Let's keep things as they are currently based on the steering group's original feedback, and if there are other protocols/types that folks want to discuss further, we can use the proposal review thread for those.

allevato

Thank you for the updates! Getting ready to merge and start the review.

nate-chandler added 4 commits February 9, 2024 14:16

[BitwiseCopyable] Pitch draft.

2db89d8

[BitwiseCopyable] Add new stdlib API.

ad5ab9b

Overload existing public stdlib functions on a BitwiseCopyable constraint to allow for ideal code generation for conforming types.

[BitwiseCopyable] Describe inference suppression.

d9d7774

allevato reviewed Feb 29, 2024

View reviewed changes

nate-chandler added 2 commits March 4, 2024 16:26

[BitwiseCopyable] Remove a few stdlib conformances

41eaf91

Per LWG feedback, these three conformances don't make sense.

[BitwiseCopyable] Note conformance of Float16.

9f63c40

Its omission was an oversight.

nate-chandler added 4 commits March 4, 2024 17:06

[BitwiseCopyable] Inference for raw-value enums.

8811170

Clarified that it depends on the actual enum, not the `RawValue` type witness of the synthesized `RawRepresentable` conformance.

[BitwiseCopyable] Future direction for composition

0303bea

[BitwiseCopyable] Inference for imported types.

e4d4627

[BitwiseCopyable] Removed from FixedWidthInteger.

c98781f

benrimmington reviewed Mar 6, 2024

View reviewed changes

allevato approved these changes Mar 6, 2024

View reviewed changes

Assign SE-0426 to BitwiseCopyable.

00d8a08

allevato merged commit d44ebbf into swiftlang:main Mar 6, 2024

nate-chandler deleted the bitwise-copyable branch March 6, 2024 19:56

nate-chandler mentioned this pull request Mar 28, 2024

[BitwiseCopyable] Allow suppression via ~. swiftlang/swift#72646

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BitwiseCopyable] Pitch. #2314

[BitwiseCopyable] Pitch. #2314

nate-chandler commented Feb 9, 2024

allevato left a comment

allevato Feb 29, 2024

nate-chandler Mar 6, 2024

allevato Feb 29, 2024

nate-chandler Mar 6, 2024

allevato Feb 29, 2024

tbkka Feb 29, 2024

nate-chandler Mar 6, 2024

allevato Mar 6, 2024

stephentyrone Mar 6, 2024

nate-chandler Mar 6, 2024

allevato Feb 29, 2024

nate-chandler Mar 6, 2024

allevato Feb 29, 2024

nate-chandler Mar 6, 2024

nate-chandler commented Mar 5, 2024

benrimmington Mar 6, 2024

allevato Mar 6, 2024

allevato left a comment


		### Inference for types in evolving libraries

		This does not apply to public (or `@usableFromInline`) types defined within a module built with library evolution.


		For an exhaustive list, see the [appendix](#all-stdlib-conformers).

		### Additional BitwiseCopyable types


		The following protocols in the standard library will gain the `BitwiseCopyable` constraint:

		- `FixedWidthInteger`

[BitwiseCopyable] Pitch. #2314

[BitwiseCopyable] Pitch. #2314

Conversation

nate-chandler commented Feb 9, 2024

allevato left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nate-chandler commented Mar 5, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

allevato left a comment

Choose a reason for hiding this comment