[swift-evolution] ternary operator ?: suggestion

[Craig Cruden]

I am not worried about the door being open - it should always be open… but then to get through the door it has to be more difficult (otherwise you become the PL/1 of the modern era).  

Although I don’t see any need for fully implementing partial functions in it’s most general form — and don’t think it would be very easy at all — it does not mean future proposals might come up with a very innovative reason why it is needed in the future. 




> On 2016-01-20, at 15:52:41, Thorsten Seitz <tseitz42 at icloud.com> wrote:
> 
> I agree with you.
> 
> On the other hand the partial functions cannot exist outside of a total closure so I'm wondering whether it makes sense giving that concept a name. It might keep the door open to make partial functions explicit in the future, though (although I'm still not convinced we need them due to Swift's lightweight optional syntax).
> 
> -Thorsten 
> 
> Am 20.01.2016 um 08:23 schrieb Craig Cruden <ccruden at novafore.com <mailto:ccruden at novafore.com>>:
> 
>> Yes and No.
>> 
>> A single case in the closure is a partial function.  The fact that you have to union them with other partial functions before you can use them inside a closure.  So the closure is total, but it is composed of a union of partial functions.  
>> 
>> NOTE: not necessarily union if the partials overlap but I could not think of another word.
>> 
>>> On 2016-01-20, at 13:07:00, Thorsten Seitz <tseitz42 at icloud.com <mailto:tseitz42 at icloud.com>> wrote:
>>> 
>>> Sorry, I meant "partial function", not "partial closure".
>>> In Scala that term makes sense as the partiality is exposed there. In the proposal it is not used, because totality is required. So I was thinking about dropping the term from the proposal. The alternatives section might note that Scala's partial functions were considered but that exhaustiveness checks were considered more important and partial functions might easily be simulated be returning an optional.
>>> But you are right that some catching term would be needed. Hmm, maybe "case closures"?
>>> 
>>> -Thorsten 
>>> 
>>> 
>>> Am 20.01.2016 um 06:32 schrieb Craig Cruden <ccruden at novafore.com <mailto:ccruden at novafore.com>>:
>>> 
>>>> “partial closure” might not be the best term, but so far I I don’t think any of the terminology that I have heard is as short or catchy ….  
>>>> 
>>>> But I will think about it.
>>>>> On 2016-01-20, at 6:10:59, Thorsten Seitz <tseitz42 at icloud.com <mailto:tseitz42 at icloud.com>> wrote:
>>>>> 
>>>>> Actually I’m not sure about introducing the term "partial closure“ because the proposal does not make use of their partiality in any way (like Scala does with the method isDefinedAt() or the chaining methods) and on the contrary requires their combination to be a total function (which is a good thing IMO). As I already wrote in another mail a couple of days before I think in Swift partial functions can simply be formulated by making the return type an optional which I think fits Swift nicely because of its lightweight syntax of optionals.
>>>>> So I don’t think there is a need for partial functions in Swift and therefore I probably would not introduce that term but instead propose a new lightweight syntax for defining unary closures where
>>>>> 
>>>>> { x in 
>>>>>     switch x {
>>>>>     case pattern: return expr
>>>>>     default: return expr
>>>>>     }
>>>>> }
>>>>> 
>>>>> can simply be written as
>>>>> 
>>>>> { 
>>>>>     case pattern: expr
>>>>>     default: expr
>>>>> }
>>>>> 
>>>>> Does that make sense?
>>>>> 
>>>>> -Thorsten
>>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160120/542e38a8/attachment.html>