[Second review] SE-0390: Noncopyable structs and enums

Evolution Proposal Reviews
50
Are we sure that a protocol is the right way to model copyability?

I've hidden this text to minimize the noise I may add to the thread, specifically because it was stated clearly that the proposal has been accepted in principle and the only feedback being sought is on the exact punctuation mark to be used, but I had a somewhat negative reaction just now when reading the proposal because of how many aspects of the current design seem special-case-y/convoluted, so I wanted to at least say that and explain why (in a non-obtrusive way):

  • The proposal starts out by introducing the ~Copyable syntax for declaring a struct or enum as not-yet-copyable. The syntax makes Copyable seem mostly like a protocol (except for the somewhat unsettling new ~ sigil), but so far it doesn't need to be. We could imagine many variations on the current struct/enum declaration syntax that gives us the option to declare them as noncopyable.

  • The proposal then goes on to describe the rules about composition involving noncopyable types. Still nothing protocol-y going on in this section. It's more reminiscent of the constellation of rules that were being discussed when actors were still slated to be melded with class-inheritance (thanks to Chris Lattner for helping us avoid that).

  • Then the proposal describes the various (sweeping, even) ways in which Copyable cannot be used like a normal protocol. At least now the modeling as a protocol is acknowledged, but rather than being backed up as being the best approach it seems to me that that argument is weakened.

  • Then comes the section titled "The Sendable Exception", in which the proposal expands upon more special-case-rules that the design obliges.

  • Then a section about some workarounds for the limitations with generics.

  • Then a lot more (involving consume, borrow, etc.), which I don't have time to fully process, but which isn't necessary for me to process yet because I'm just making the case that the proposal brought up a major doubt for me (why Copyable is modeled as a protocol-ish-thing), which was only compounded as I continued to read, so if my concerns are clearly addressed further down in the proposal and I missed it by only reading half of the proposal then my only suggestion is to move that part higher up in the document so that the proposal doesn't have to be processed all at once in order to seem solid to the reader (and in which case I would also be glad I minimized the visual impact of this critique on this thread).

3 Likes