[swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng]

I'm honestly not sure it makes sense to introduce a proposal just for
expressing <Class, Protocol, Protocol> style requirements, and then trying
to retrofit fuller support for other existentials onto it. I would prefer
that the 'basic package' of existential cases be considered together as a
single proposal, unless a core team member expresses their preference
otherwise.

Austin

On Tue, May 17, 2016 at 1:02 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On May 17, 2016, at 2:45 PM, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Feel free to add as much of this proposal into yours as you want.
>
>
> The trend is towards smaller proposals and introducing change in stages.
> Since Adrian’s proposal is almost ready it’s probably best to move ahead
> with it as-is and follow up with generalized existentials (yours), and then
> possibly a third on “opening” existentials.
>
>
> 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
>>
>>
> _______________________________________________
> 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/0861af26/attachment.html>