[swift-evolution] [Draft] Expanded min/max algorithms

[Matthew Johnson]

> On Apr 18, 2016, at 11:08 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
> On Sun, Apr 17, 2016 at 11:10 AM, Matthew Johnson via swift-evolution
> <swift-evolution at swift.org> wrote:
>> These extension points are effectively “optional protocol requirements”.
> 
> I'm sorry, but they are not optional requirements.  They are
> workarounds for a language issue -- inability to make
> conditionally-available methods customizable by a conforming type.

I understand that they are not optional requirements as they exist in the language today.  What I meant is that the approach these extension points are taking is effectively the same as one of the approaches discussed in the "How to eliminate 'optional' protocol	requirements” thread.  

I am referring to the first option in Doug’s initial message: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160404/014471.html.  Doug considered this unworkable but Joe considers the reasons Doug called it unworkable to be missing language features that should exist anyway: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014696.html.  There has not yet been a resolution on this issue.

The primary difference between that approach and your extension points is that you add and extra level of optionality to the value returned whereas the approach in that thread has an optional closure property.  Both approaches use a default implementation of “return nil” to indicate that there is no customization requested by the implementer.

In your proposal the extension points look like this:

func _customMinComparableElement() -> Iterator.Element??

Translating to the option Doug presented they would look like this:

var _customMinComparableElement: (() -> Iterator.Element?)? { get }

In either case a default implementation that returns nil would be provided.  Under Doug’s model where methods can be used to implement such requirements, implementers would provide a method like this:

func _customMinComparableElement() -> Iterator.Element?

I hope I have clarified how I believe these extension points are related to the thread about removing optional protocol requirements from the language.  My opinion is that if we are going to remove them and import them from Objective-C in a more Swifty way by embedding the optionality in the type system that same mechanism should be used by any extension points which behave similarly.

Matthew

> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160418/731e11a3/attachment.html>