SE-0427: Noncopyable Generics

As of last night's (the 19th) nightly toolchain, the standard library now has support for noncopyable generics on its pointer types and on Optional (gated under the -enable-experimental-feature NoncopyableGenerics of this proposal – though there is also another step needed which is to run a review for that addition, pitch tk).

This is very relevant for folks wanting to try out this feature, since it's very hard to do anything useful with noncopyable generics without these basic building blocks.

To see a simple example of this adoption, here is a PR I put up on the Swift Playdate sample code that was recently released. This adds a very basic non-copyable array type, and then uses that to store the brick sprites.

Previously these sprites had to be represented as an enum (indicating ownership) plus a class (to handle deallocation). The noncopyable version of that pattern is significantly simpler: it just holds the underlying opaque pointer (the playdate SDK's sprite handle) plus a bool to track ownership, then uses a struct with a deinit to free it if necessary.

The PR also adds a basic array type to hold the brick sprites. This is partly because Swift.Array does not yet support non-copyable elements (doing so requires more discussion of what it means for the collection protocol hierarchy) but also because adopting a much simpler type that does not need to worry about ref counting or growing has meaningful benefits to binary size in an embedded context.

Note, please direct discussion of this change itself to either the PR or the thread on the playdate example rather than this review thread. But of course, feedback on the proposal itself citing examples from that code are welcome here.

10 Likes