SE-0244: Opaque Result Types (reopened)

[anandabits (Matthew Johnson)]

@Paul_Cantrell

This example also raises many more questions! I wonder, for example, about this code (using the hypothetical any/some syntax), which if I understand correctly would not compile:

func nthOfEach(
  _ n: Int,
  from heterogeneousCollections: [any Collection]
) -> Any {
  return heterogeneousCollections.map { collection in  // collection is `any Collection`
    let nthIndex = collection.startIndex.advanced(by: n)

    // error: inferred static type of nthIndex is something like `any Collection.Index`,
    // so compiler can’t guarantee it indexes `collection` … correct?
    return collection[nthIndex]
  }
}

Would this then also not compile, for the same reasons?

  return heterogeneousCollections.map { collection in
    return collection[collection.startIndex.advanced(by: n)]
  }

These examples require “path-dependent types” to work. There are some examples in the old enhanced existentials draft (although it does not use the term path-dependent types).

Also, fwiw Scala’s type system supports this feature. I don’t know Scala in depth so I’m not sure how closely it relates to what we might have in Swift but you might find it interesting to look at how Scala handles this.

@Paul_Cantrell

return heterogeneousCollections.map { (collection: some Collection) in return collection[collection.startIndex.advanced(by: n)] }

This would require a map overload in a conditional extension constrained to where Element was an existential, and for which we could name the constraints applied to the existential so they could be used as constraints on the opaque transform parameter type. I’m not sure how we might express that or how useful it would be, but it’s an interesting direction to think about.