[swift-evolution] [Proposal draft] Remove objc requirement for optional protocol methods/properties

[Douglas Gregor]

> On Jan 11, 2016, at 12:08 AM, David Scrève <david.screve at dlta-studio.com> wrote:
> 
>> 
>> Le 11 janv. 2016 à 05:56, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> a écrit :
>> 
>> 
>>> On Jan 10, 2016, at 1:31 AM, David Scrève via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hi Chris,
>>> 
>>>> Le 10 janv. 2016 à 02:29, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> a écrit :
>>>> 
>>>>> 
>>>> 
>>>> This is certainly a glaring hole in the system, and one we need to discuss.  Here are some problems with making optional requirements a first class thing in Swift:
>>>> 
>>>> 1. They overlap heavily (but are syntactically privileged) with optional properties, consider the difference between "optional func f() -> Int"  vs "var f : (() -> Int)?  {get}”.
>>> 	You are right. I suggest that we restrict optional keyword in protocol to methods only to fix this issue and keep the actual meaning.
>> 
>> That wasn’t Chris’s point. Compare
>> 
>> 	protocol P {
>> 	  optional func f() -> Int
>> 	}
>> 
>> with
>> 
>> 	protocol P {
>> 	  var f: (() -> Int)? { get }
>> 	}
>> 
>> 	extension P {
>> 	  var f: (() -> Int)? { return nil }
>> 	}
>> 
>> Both will have the same “call-side” syntax, e.g., accessing the “f” member of something that conforms to “P” gives you a value of type “(() -> Int)?”. You can use ? to optionally call it like so:
>> 
>> 	func testF<T : P>(t: T) {
>> 	  let x = t.f?() // call “f’ if it is available.
>> 	}
> 
> 	Yes, I agree with you…I didn’t read carefully the answer from Chris. But the implementation is more complex : 
> 
> struct Person {
>     let name:String
>     let surname:String
> }
> 
> protocol PersonRetrievable {
>     var personDescription : String { get }
>     var loadPerson:(() -> Person)? { get }
> }
> 
> extension PersonRetrievable {
>     var loadPerson:(() -> Person)? { return nil }
> }
> 
> class GroupPerson : PersonRetrievable {
>     var personDescription : String {
>         return "Hello World";
>     }
>     
>     var loadPerson:(() -> Person)? {
>         return { return Person(name: "Scrève", surname: "David")}
>     }
> }
> 
> 	Double returns is quite complex to write and understand..but I agree this problem can be solved like this.

Right. One could extend the language with a rule that allows a method to satisfy a read-only property requirement when that property is of (possibly optional) function type.


> 
>> 
>> 
>>> 	Java has introduced default implementation in interface and it create confusion between classes and interfaces and does not solve the issue I exposed below.
>> 
>> We already have default implementations for protocols (via extensions) as well as classes with implementation inheritance, so any related confusion is already there, so I don’t see how the comparison matters.
> 
> 	Another question is about priority : Is there any guarantee that implementation of protocol will be called instead of extension ? I don’t remembre reading this anywhere.

The rules are a little muddy and are being discussed in other threads (e.g., those about dynamic dispatch of members of protocol extensions).

>>> 	I think we should keep the actual model by limiting optional keyword to methods, which has really a meaning. 
>> 
>> I don’t see why you would limit it to methods. There are a number of optional properties in Cocoa[Touch], for example, and it “wrap the result in an extra level of optional” is a reasonable semantic approach here.
> 
> 	I wrote that because properties already have optional behavior with their type.
> 
> 	Another idea would be to remove the optional keyword and use the same syntax for method with question mark : 
> 
>     func loadPerson?()
> 
> 	And the compiler generates the code with the double return and property. 
> 
> 	What do you think about this ?

Per my first comment about about satisfying a read-only property of function type with a method, I don’t think we need a special syntax at all to make it easy to conform to these protocols.


	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160111/5d0c98d6/attachment.html>