[swift-evolution] Type information containing multiple additional protocols

[Kevin Ballard]

Oh that's clever. I like that. It doesn't have a big impact on the
language and it makes reasonable sense when read. We could also
establish convention (possibly backed up by warnings) that says that if
Any<...> contains a class, the class name must come first.

-Kevin Ballard

On Tue, Dec 15, 2015, at 06:27 PM, Jordan Rose via swift-evolution wrote:
> At one point we talked about co-opting "Any" for this purpose, i.e.
> replacing the "protocol<…>" syntax with "Any<…>". Like a concrete
> type, you're not required to provide arguments, so "Any" by itself
> doesn't change meaning. Like an inheritance clause, the compiler would
> check if you ever had more than one class there.
>
> Jordan
>
>> On Dec 4, 2015, at 23:38 , Jacob Bandes-Storch
>> <jtbandes at gmail.com> wrote:
>>
>> I think this is a very useful feature of Obj-C that I've missed
>> several times while writing Swift code.
>>
>> However, calling it "TheClass<Protocol1, Protocol2>" directly
>> conflicts with the syntax for specifying generic type parameters.
>>
>> If we use "protocol<TheClass, Protocol1, Protocol2>" for this case,
>> then `protocol` stops making sense. Maybe the keyword `class` could
>> be allowed instead, like "class<TheClass, Protocol1, Protocol2>".
>>
>> Or, it might work to omit the keyword entirely, leaving only the
>> angle brackets:
>>
>> class C {    weak var delegate: <UIViewController,
>> UICollectionViewDelegate>? }
>>
>> if let task = object as? <NSManagedObject, Task> {
>> task.coreDataRelatedFunction()    task.taskRelatedFunction() }
>>
>> Jacob Bandes-Storch
>>
>> On Fri, Dec 4, 2015 at 3:07 PM, Daniel
>> Muhra<daniel.muhra at gmail.com>wrote:
>>> Currently it doesn’t seem possible to define a property or variable
>>> of a specific class that also implements one or more protocols. Take
>>> as an example the following definition from Objective C:
>>>
>>> NSManagedObject<NSCoding, Task>* someObject;
>>>
>>> To my knowledge, currently it is only possible to define multiple
>>> protocols only:
>>>
>>> var object : protocol<NSCoding, Task>
>>>
>>> However, given the first example, sometimes it is not possible to
>>> restrict to protocols only. This becomes especially cumbersome, if
>>> you would need to cast down to such a construct within a single
>>> method and perform several steps which would require all those type
>>> information:
>>>
>>> funcdoSomething(object:AnyObject) { ifletmanagedObject =
>>> objectas?NSManagedObject{ // Do core data related stuff }
>>>
>>> iflettask = objectas?Task{ // Do task related stuff  } }
>>>
>>> In this case you now have managedObject and task though you operate
>>> on the same object. Also it is not (easily) possible to interleave
>>> actions of those two.
>>>
>>> My first idea here would be to introduce an Objective C like style
>>> of type naming. This also has the benefit, that it is perfectly
>>> clear, whether a type name refers to a class or a protocol (without
>>> first having to check it). The downside, of course, is that protocol
>>> type variables would become something like Any<MyProtocol>
>>>
>>> Any other ideas are welcome, but the initial problem still stands
>>> and should be addressed.
>>>
>>>
>>> _______________________________________________
>>> 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/20151215/0df45199/attachment.html>