[Pitch] Box

Evolution Pitches
55

I’m generally supportive of this proposal. However, I’m hesitant about the method name clone().

While I understand the motivation to align with a potential future Clonable protocol, adopting this name now feels like it sets a specific precedent for a feature that hasn't been fully explored yet.

I have a few concerns with stabilizing clone() at this stage:

  • Naming Flexibility: We might eventually decide that Clonable isn't the right name for the protocol (e.g., we might prefer ExplicitlyCopyable or something entirely different) or that the method should be named differently. Using clone() here leans heavily in one direction before that debate has happened.
  • Namespace Pollution: If Copyable eventually refines this future protocol (as suggested in Future Directions), we risk a future where every copyable type gains a redundant .clone() method. This could clutter the namespace and clash with existing user-defined methods. We would likely need disambiguation rules, compiler quirks to hide clone() when conformance to Copyable is visible, or linters to catch redundant calls to clone().
  • Previous discussions regarding explicit copying explored using a copy operator (copy x) to mirror consume and borrow. If the language adopts a copy operator for types conforming to this new protocol, Box having a .clone() method would create an awkward inconsistency in vocabulary.

I'd suggest we stick to the terminology we have today - "copy" - either as an initializer or a method.

extension Box where Value: Copyable {
  public init(copying source: borrowing Box<Value>)
  // or
  public func copy() -> Box<Value>
}

Personally, I prefer the initializer approach. If Swift adopts a Deref-like mechanism (as mentioned in Future Directions), Box having a method named copy() creates potential ambiguity if the wrapped value also has a copy() method. An initializer avoids this collision entirely.

3 Likes