[swift-evolution] ternary operator ?: suggestion
Thorsten Seitz
tseitz42 at icloud.com
Wed Jan 20 00:07:00 CST 2016
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>:
>
> “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> 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/e2bc9280/attachment.html>
More information about the swift-evolution
mailing list