[swift-evolution] [Pre-proposal/Question] Exposing the Unboxing Capabilities of AnyIndex (and similar types)

Haravikk swift-evolution at haravikk.me
Thu Jun 9 03:26:22 CDT 2016

> On 8 Jun 2016, at 20:53, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> on Wed Jun 08 2016, Haravikk <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> But those shouldn't be the public names.  Perhaps s/box/wrap/ ?

True! So I’m thinking I’ll try to come up with a basic proposal soon, I’m just thinking about how this would be implemented. For example, it may make sense to do this as a protocol that AnyIndex (and other suitable types) can just conform to like so:

	protocol Unwrappable {
		associatedtype UnwrappedType
		func unwrap<T:UnwrappedType>() -> T?
		func unsafeUnwrap<T:UnwrappedType>() -> T

I’ve kept the ability to specify a root type that unwrapping can produce, i.e- Comparable in the case of AnyIndex. Not too happy with the name of UnwrappedType, since it’s not intended to be the exact type in most cases, not sure what would be a more appropriate name. Also I lost track of the discussion about common root types between value and reference types; is there a type in Swift that could be used when unwrapping can produce absolutely anything (struct, enum, object etc.)? If not it may be better to drop the associated type and just lose the extra type-checking benefit.

I’m still struggling to come up with other types that definitely need this, as all the other AnyFoo types I can think of expose functionality of the underlying type that you can use, so the need to unwrap them doesn’t really come up. But with a protocol defining this the capability will be there to expand this quickly to other types later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160609/eca2b330/attachment.html>

More information about the swift-evolution mailing list