> On Feb 1, 2017, at 2:09 PM, David Hart <[email protected]> wrote:
>
> I did consider it, but didn’t want to put too much on your plate for Swift 4.
Quite appreciated! Cleaning up AnyObject happens to be on my list of
ABI-impacting changes I’m itching to make ;)
> But if you’re mentioning it, I’ll go ahead and add it to the second version
> of the proposal.
Thanks!
> By the way, what you is your point of view about the discussions we’ve had
> concerning the positioning of the class constraint?
Personally, I like having the requirement that the class come first. It fits
with the requirement we already have for classes that have a superclass.
- Doug
> David.
>
>> On 1 Feb 2017, at 22:58, Douglas Gregor <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Jan 29, 2017, at 8:39 AM, David Hart <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hello,
>>>
>>> As promised, I wrote the first draft of a proposal to add class
>>> requirements to the existential syntax. Please let me know what you think.
>>>
>>> https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md
>>>
>>> <https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md>
>> This looks good! I’m looking forward to the second draft, but I have one
>> question.
>>
>> Did you consider the generalized “class” constraint? IIRC, this was in
>> Austin’s larger proposal, and it allowed for (e.g.)
>>
>> typealias CustomStringConvertibleClass = class &
>> CustomStringConvertible // class that conforms to CustomStringConvertible
>>
>> and potentially a wonderful cleanup where AnyObject ceases to be a weird
>> special protocol and instead becomes
>>
>> typealias AnyObject = Any & class
>>
>>
>> - Doug
>>
>>> Regards,
>>> David.
>>>
>>> Existentials for classes conforming to protocols
>>>
>>> Proposal: SE-XXXX
>>> <https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md>
>>> Authors: David Hart <http://github.com/hartbit/>, Austin Zheng
>>> <http://github.com/austinzheng>
>>> Review Manager: TBD
>>> Status: TBD
>>>
>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#introduction>Introduction
>>>
>>> This proposal brings more expressive power to the type system by allowing
>>> Swift to represent existentials of classes and subclasses which conform to
>>> protocols.
>>>
>>>
>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#motivation>Motivation
>>>
>>> Currently, the only existentials which can be represented in Swift are
>>> conformances to a set of protocols, using the &syntax:
>>>
>>> let existential: Hashable & CustomStringConvertible
>>> On the other hand, Objective-C is capable of expressing existentials of
>>> subclasses conforming to protocols with the following syntax:
>>>
>>> UIViewController<UITableViewDataSource, UITableViewDelegate>* existential;
>>> We propose to provide similar expressive power to Swift, which will also
>>> improve the bridging of those types from Objective-C.
>>>
>>>
>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#proposed-solution>Proposed
>>> solution
>>>
>>> The proposal keeps the existing & syntax but allows the first element, and
>>> only the first, to be of class type. The equivalent declaration to the
>>> above Objective-C declaration would look like this:
>>>
>>> let existential: UIViewController & UITableViewDataSource &
>>> UITableViewDelegate
>>> As in Objective-C, this existential represents classes which have
>>> UIViewController in their parent inheritance hierarchy and which also
>>> conform to the UITableViewDataSource and UITableViewDelegate protocols.
>>>
>>> As only the first element in the existential composition syntax can be a
>>> class type, and by extending this rule to typealias expansions, we can make
>>> sure that we only need to read the first element to know if it contains a
>>> class requirement. As a consequence, here is a list of valid and invalid
>>> code and the reasons for them:
>>>
>>> let a: Hashable & CustomStringConvertible
>>> // VALID: This is still valid, as before
>>>
>>> let b: MyObject & Hashable
>>> // VALID: This is the new rule which allows an object type in first position
>>>
>>> let c: CustomStringConvertible & MyObject
>>> // INVALID: MyObject is not allowed in second position. A fix-it should
>>> help transform it to:
>>> // let c: MyObject & CustomStringConvertible
>>>
>>> typealias MyObjectStringConvertible = MyObject & CustomStringConvertible
>>> let d: Hashable & MyObjectStringConvertible
>>> // INVALID: The typealias expansion means that the type of d expands to
>>> Hashable & MyObject & CustomStringConvertible, which has the class in the
>>> wrong position. A fix-it should help transform it to:
>>> // let d: MyObjectStringConvertible & Hashable
>>>
>>> typealias MyObjectStringConvertible = MyObject & CustomStringConvertible
>>> let e: MyOtherObject & MyObjectStringConvertible
>>> // INVALID: The typealias expansion would allow an existential with two
>>> class requirements, which is invalid
>>> The following examples could technically be legal, but we believe we should
>>> keep them invalid to keep the rules simple:
>>>
>>> let a: MyObject & MyObject & CustomStringConvertible
>>> // This is equivalent to MyObject & CustomStringConvertible
>>>
>>> let b: MyObjectSubclass & MyObject & Hashable
>>> // This is equivalent to MyObjectSubclass & Hashable
>>>
>>> typealias MyObjectStringConvertible = MyObject & CustomStringConvertible
>>> let d: MyObject & MyObjectStringConvertible
>>> // This is equivalent to MyObject & CustomStringConvertible
>>>
>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#source-compatibility>Source
>>> compatibility
>>>
>>> This is a source breaking change. All types bridged from Objective-C which
>>> use the equivalent Objective-C feature import without the protocol
>>> conformances in Swift 3. This change would increase the existential's
>>> requirement and break on code which does not meet the new protocol
>>> requirements. For example, the following Objective-C code:
>>>
>>> @interface MyViewController
>>> - (void)setup:(nonnull
>>> UIViewController<UITableViewDataSource,UITableViewDelegate>*)tableViewController;
>>> @end
>>> is imported into Swift 3 as:
>>>
>>> class MyViewController {
>>> func setup(tableViewController: UIViewController) {}
>>> }
>>> which allows calling the function with an invalid parameter:
>>>
>>> let myViewController: MyViewController()
>>> myViewController.setup(UIViewController())
>>> The previous code would have worked as long as the Objective-C code did not
>>> call any method of UITableViewDataSource or UITableViewDelegate. But if
>>> this proposal is accepted and implemented as-is, the Objective-C code would
>>> now be imported as:
>>>
>>> class MyViewController {
>>> func setup(tableViewController: UIViewController &
>>> UITableViewDataSource & UITableViewDelegate) {}
>>> }
>>> That would then cause the Swift code to fail to compile with an error which
>>> states that UIViewController does not conform to the UITableViewDataSource
>>> and UITableViewDelegate protocols.
>>>
>>> It is a source-breaking change, but should have a minimal impact for the
>>> following reasons:
>>>
>>> Not many Objective-C code used the existential syntax in practice.
>>> There generated errors are a good thing because they point out potential
>>> crashes which would have gone un-noticed.
>>>
>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#alternatives-considered>Alternatives
>>> considered
>>>
>>> None.
>>>
>>>
>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#acknowledgements>Acknowledgements
>>>
>>> Thanks to Austin Zheng <http://github.com/austinzheng> and Matthew Johnson
>>> <https://github.com/anandabits> who brought a lot of attention to
>>> existentials in this mailing-list and from whom most of the ideas in the
>>> proposal come from.
>>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
