[swift-evolution] Specify type of a delegate which conforms to a protocol

[Alex Hoppen]

> On 09 Feb 2016, at 21:00, davesweeris at mac.com wrote:
> 
> That might solve Inder’s problem, but strictly speaking it doesn’t actually restrict the type to an enum. This struct meets all of RawRepresentable’s requirements:
> struct Foo : RawRepresentable {
>     typealias RawValue = String
>     init?(rawValue: Foo.RawValue) {
>         return nil
>     }
>     var rawValue: RawValue = "bar"
> }
> 
> (Although in practice I can’t think of why that would matter, since you can’t do anything with a RawRepresentable other than get it’s rawValue or call init?(rawValue: String), and neither of those rely on enum features… I’ll stop being pedantic now.)

OK, your right, maybe my example was badly chosen. RawRepresentable was the first protocol with an associated type that came into my mind. But the same issue applies for a number of protocols as well, e.g. ArrayLiteralConvertible with associated value Element. Apart from the fact that I don’t like not being able to specify all variable types, you may want to use this in practice to store the values of an Array literal and decide later in what kind of data structure you would like to use to hold the values in the long term.

> 
> Anyway, the bigger point is that there’s no way to restrict a generic type to be an enum. I think it’s because there wouldn’t be a way to switch on it (or do other enum-ish things) without knowing all its cases, which requires knowing exactly which type it is, which means it’s no longer a generic type. That’s just a guess, though.
> 
> Maybe someone should propose that we allow something like this:
> func foobar <T, U where T: (case .foo, case .bar)> (value: T) -> U {
>     switch value {
>     case .foo: ...
>     case .bar: ...
>     }
> }
> 

If you specify all the cases your enum should have, you could just specify the enum as well. The list would have to be exhaustive anyway so that the compiler can check that all cases have been covered in a switch statement and I can’t think of any reason why it would be useful to have two enums with exactly the same cases.

> 
> - Dave Sweeris
> 
>> On Feb 9, 2016, at 10:47, Alex Hoppen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> As for a new syntax, I was also thinking about this issue a few days ago and it occurred to me that there are even more types that cannot be properly represented in Swift. For example there is currently no way (that I know of) to create a variable that can contain any enum that is backed by a String. However, these kinds of constraints can easily be specified in generic constraints (the ones in angle brackets). Maybe we could add the same syntax for variables/constants as well so that the code would look something like the following for your issue:
>> 
>> var<T, where T: UIViewController, T: MyProtocol> myVar: T
>> 
>> or for enums backed by a String:
>> 
>> var<T: RawRepresentable where T.RawValue == String> myVar: T
>> 
>> Tell me what you think about it.
>> 
>> - Alex
>> 
>> 
>>> On 09 Feb 2016, at 15:58, Inder Kumar Rathore . via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hi All,
>>> I used to do this in Obj-C but I'm unable to do this in swift
>>> 
>>> UIViewController<MyProtocol> *delegate;
>>> 
>>> I posted this question on dev forums but didn't get the solution and finally I'm reporting here so that It can be added as a features in the coming releases.
>>> 
>>> Thanks
>>> 
>>> Rathore
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160209/c8a56bbf/attachment.html>