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

[David Scrève]

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.
> 
> 2. Protocols with default implementations provide the vastly most common use-cases for these.
> 
> 3. They overload “optional” terminology in the language to mean something different.
> 
> 4. They are non-sensical - how can something be a requirement and be optional? :)
	Actually, optional methods allow to add methods to interface without breaking existing code and for me, conforming to protocol means « you can optionally implement this methods but you must implements others ». Conforming does not mean implements all feature but the protocol defines minimum requirements.

> 
> Doug has it on his plate to explore what we can do about this, in the Swift 3 timeframe, but not in the immediate future.  IMO, it would be really great if we could make Objective-C optional requirements disappear in the Clang importer, and transform them into requirements with a default implementation.
> 
	I agree that default implementation seems to be the right solution but I’m afraid it introduces other problems with scope.

	Consider the UITableViewDataSource protocol and the heightForRowAtIndexPath. The default implementation method uses UITableView internal properties and methods. Then, if we provide default implementation for this method in protocol, we will need to reference the called object in protocol.

	Actually, the default implementation may depend of the caller and can be different for each caller in the actual model. 

	If you attach default implementation to protocol declaration, you will not be able to have caller specific default implementation and will have a basic and quite useless default implementation i.e. returning nil or invalid value.

	I thing this is a major issue because ObjC default implementation behavior is really powerful.

	One workaround would be to provided default implementation when declaring delegate attribute, but this would make syntax very complicated.

	Java has introduced default implementation in interface and it create confusion between classes and interfaces and does not solve the issue I exposed below.

	I think we should keep the actual model by limiting optional keyword to methods, which has really a meaning. 

	Anyway, I did not think about this before Swift 3 or later.

David



-------------- 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/20160110/8fecb9f3/attachment.p7s>