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

[David Scrève]

> Le 11 janv. 2016 à 05:56, Douglas Gregor <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> wrote:
>> 
>> Hi Chris,
>> 
>>> Le 10 janv. 2016 à 02:29, Chris Lattner <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.

> 
> 
>> 	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.

> 
>> 
>> 	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 ?

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160111/e1349f29/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4233 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160111/e1349f29/attachment.p7s>