[swift-evolution] Brainstorming: Optional sugar inferred map

Robert S Mozayeni r at mzy.me
Thu Jan 28 02:29:04 CST 2016


+1 for Paul and Jacob’s ideas.

I’m not a fan of the original example, because then you could just have one optional variable or constant that just cascades through your code and gives everything an inferred Optional type, and then you lose the power of optionals because the compiler doesn’t make you check for them. Here’s an example for where that could go awry:

Let's say you're writing code that takes a String from user input somewhere and parses it into an Int.

let numCaloriesJustEaten = Int(userInputString) //Let's say userInputString is `two`. Type inferred as `Int?`, and would have value of nil
dict["caloricConsumption"] = numCaloriesJustEaten + (dict["caloricConsumption"] ?? 0)

The intention of this code would be to increment caloricConsumption by the recently-eaten calories. In Swift, this (rightfully) wouldn’t compile. If Swift operated according to the original example, then the whole expression of `numCaloriesJustEaten + (dict["caloricConsumption"] ?? 0)` would compile, and would have a value of nil at runtime.
This would remove the value of `dict["caloricConsumption”]` because when you set a the value of a key to nil, it removes that key from the dictionary entirely. This would be a logic error that is currently caught as a compile-time error in Swift today.

-Robert

> On Jan 28, 2016, at 2:34 AM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I've wanted this sort of thing a lot. It would also work for other functions, such as
> 
>     manager.doSomething(data: data, count: n?)
> 
> which is equivalent to
> 
>     n.map { manager.doSomething(data: data, count: $0) }
> 
> It might be hard to see exactly which operator/function applications such a thing applies to, if used in the context of a complex expression.
> 
> Jacob
> 
> On Wed, Jan 27, 2016 at 9:50 PM, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Maybe something like this?
> 
> let n : Int? = 5
> 
> let r = n? + 5
> 
> 
>> On Jan 27, 2016, at 9:46 PM, Thorsten Seitz <tseitz42 at icloud.com <mailto:tseitz42 at icloud.com>> wrote:
>> 
>> Too much hidden magic IMO. This would mean loosing the benefits of optionals, i.e. making explicit where optional cases occur and that handling the missing case has to be considered. 
>> 
>> -Thorsten 
>> 
>> Am 28.01.2016 um 06:30 schrieb Craig Cruden via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>>> Yes
>>>> On 2016-01-28, at 12:28:40, Paul Ossenbruggen <possen at gmail.com <mailto:possen at gmail.com>> wrote:
>>>> 
>>>> Trying to see if I got this. So the type of r would be Int? at the end of this? And if n were nil then r would be nil? Otherwise it r is 10?
>>>> 
>>>> 
>>>> 
>>>>> On Jan 27, 2016, at 9:19 PM, Craig Cruden via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> Swift currently encourages a lot of conditional code - especially when it comes to optionals.  In most cases when you are computing etc. on an Optional you would expect that you would want an optional result and things to be able to use optionals.  
>>>>> 
>>>>> In another language I generally just `map` one optional to another - which may not be the most readable code to some not use to optionals.  
>>>>> 
>>>>> I was wondering if maybe an expression is not available that it would rewrite the syntax to map from one to another value.  
>>>>> 
>>>>> So things like:
>>>>> 
>>>>> let n : Int? = 5
>>>>> 
>>>>> let r = n + 5
>>>>> 
>>>>> would actually compile as 
>>>>> 
>>>>> let r = n.map {$0 + 5}
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/116bd64a/attachment.html>


More information about the swift-evolution mailing list