[swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng]

Feel free to add as much of this proposal into yours as you want.

Austin

On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> +1 for extending my proposal and making `Any<>` even more a powerful
> beast. :)
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution (
> swift-evolution at swift.org) schrieb:
>
> I put together the skeleton of a proposal detailing enhancements to how
> associated types can be referenced in Swift 3+. It's certainly not ready
> for submission, but I think it gets across my ideas pretty well. Would love
> to gather feedback and especially improvements.
>
> Be unsparing; whatever form this feature takes will profoundly affect how
> Swift developers program for years, so it needs to be done right.
>
> See below:
>
> *Proposal*
>
> An existential type is defined using the "Any<...>" construct. Existential
> types can be nested.
>
> The empty existential type "Any<>" is typealiased to 'Any'.
>
> Within the angle brackets are zero or more 'clauses'. Clauses are
> separated by semicolons. (This is so commas can be used in where
> constraints, below. Better ideas are welcome. Maybe it's not necessary; we
> can use commas exclusively.)
>
> There are five different possible clauses:
>
>
>    - 'class'. Must be the first clause, if present. Places a constraint
>    on the existential to be any class type. (Implies: Only one can exist.
>    Mutually exclusive with class name clause.)
>
>
> (In the future a follow-up proposal should add in 'struct' or 'value' as a
> counterpart.)
>
>
>    - Class name. Must be the first clause, if present. (Implies: Only one
>    can exist. Mutually exclusive with 'class'.) Places a constraint on the
>    existential (not really an existential anymore) to be an instance of the
>    class, or one of its subclasses.
>
> Example: Any<UIViewController; UITableViewDataSource; UITableViewDelegate>
> "Any UIViewController or subclass which also satisfies the table view data
> source and delegate protocols"
>
>    - Dynamic protocol. This is entirely composed of the name of a
>    protocol which has no associated types or Self requirement.
>
>
> Example: Any<CustomStringConvertible; BooleanType>
> "Any type which conforms to both the CustomStringConvertible and
> BooleanType protocols"
>
> I'm going to use 'static protocol' to refer to a protocol with associated
> types or self requirements. Feel free to propose a more sound name.
>
>
>    - Self-contained static protocol, simple. This is composed of the name
>    of a static protocol, optionally followed by a 'where' clause in which the
>    associated types can be constrained (with any of the three basic
>    conformance types: subclassing, protocol conformance, or type equality).
>    Associated types are referred to with a leading dot.
>
>
> Example: Any<Collection where .Generator.Element : NSObject,
> .Generator.Element : SomeProtocol>
> "Any type that is a Collection, whose elements are NSObjects or their
> subclasses conforming to SomeProtocol."
>
>
>    - Bound static protocol. This is the same as a self-contained static
>    protocol, but with a leading "<name> as " which binds the protocol to a
>    generic typealias. The name can be then be used in subsequent clauses to
>    build constraints.
>
>
> Example: Any<T as Collection; IntegerLiteralConvertible where
> .IntegerLiteralType == T.Element>.
> "Any type that is a Collection, and also can be built from an integer
> literal, in which the collection elements are the same type as the type of
> the integer used for the integer literal conformance."
>
> There will be rules to prevent recursive nesting. For example, if generic
> typealiases are allowed, they cannot refer to each other in a circular
> manner (like how structs can't contain themeselves, and you can't create a
> cyclic graph of enums containing themselves).
>
> How an existential can be used depends on what guarantees are provided by
> the clauses. For example, 'Any<Equatable>' can't be used for much; if there
> were any methods on Equatable that did not use the associated types at all
> you'd be able to call them, but that's about it. However, 'Any<Equatable
> where .Self == String>' would allow for == to be called on instances. (This
> is a stupid example, since Any<Equatable where .Self == String> is
> equivalent to 'String', but there are almost certainly useful examples one
> could come up with.)
>
> In order of increasing 'power':
>
>    - Don't constrain any associated types. You can pass around
>    Any<Equatable>s, but that's about it.
>    - Constrain associated types to conform to protocols.
>    - Fully constrain associated types.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160517/16a6022d/attachment.html>