ST-0009: Attachments

[grynspan (Jonathan Grynspan)]

@xwu

But what is "reasonable accuracy"? Besides absolute exactitude, how are users not privy to implementation detail to know what is "close enough" here?

I would compare this property, and how it would be used, to Sequence.underestimatedCount.

@xwu

I'm not sure I understand this constraint: associated types should have meaningful names, certainly, and ideally not vacuous ones, but they needn't be prefixed so that they're distinguishable from the associated types of unrelated protocols not in the hierarchy.

I'm not sure what you mean. Associated types exist in a flat namespace (within a given type). We couldn't use RawValue, as an example, without potentially conflicting with the associated type in RawRepresentable.

Although the conforming types we're including in Swift Testing don't also conform to RawRepresentable, it would not be very nice of us to prevent conformance to one protocol or the other due to mismatched requirements.

In general, the developer is not expected to ever have to type this associated type's name as it can be inferred from context anyway:

struct IntContainer: AttachableContainer {
  var attachableValue: Int // type is inferred, never to be spoken of again

  // ...
}

@xwu

So, if we go with the Wrapper terminology, then AttachableWrapper<Wrapped> or AttachableWrapper<WrappedValue> would work here.

The name AttachableWrapper is probably fine, but the associated type would likely still need to be AttachableWrappedValue or similar to avoid conflicts. I'll raise this question with the workgroup.

I will point out that the Swift project already reuses terminology to refer to different concepts. For example, Swift Testing introduced traits in Swift 6.0, and now Swift Package Manager has traits in Swift 6.1, but the features are completely unrelated.

@xwu

(While we're at it, I'd suggest Attachment<AttachedValue> would be more meaningful than Attachment<AttachableValue>: because here it's not just attach-able, it's the type of what's actually attached.)

Counterpoint: it's not attached to anything yet at the point you're dealing with an instance of Attachment, and once you attach it, your instance of Attachment is consumed.

@xwu

Although: now that I am re-reading the documentation for this particular API, is it overloading the attach[able]Value property on type?

The type of the property depends on the type of the attachable value. If it conforms to AttachableContainer, the property's type is that of the underlying value; otherwise it's that of the attachable value itself. Our expectation here is that a caller that needs to access this property is looking for the logical attachable value, not necessarily the physical attachable value.

Compare the effects LazySequence has on the transformative functions of a sequence when you add it to the mix. [1, 2, 3].map { ... } produces an array, but [1, 2, 3].lazy.map { ... } produces a LazyMapSequence (or an array, since the function is overloaded by return type. ) This isn't exactly the same scenario of course, but I see it as conceptually similar.