[swift-evolution] Brainstorming: Optional sugar inferred map

David Sweeris davesweeris at mac.com
Fri Jan 29 22:59:21 CST 2016


I'm not sure this is even possible (at least on x86/ARM), but could we do something like how the Mill CPU handles errors?

If you're not familiar with it, my understanding is that it just ignores errors (and cascades them through operations) until you try to write the invalid value to memory, at which point the exception is raised.

Seems like, in principle anyway, if Swift supported pure functions, the compiler could just silently propagate the nil until you try to store it in a non-optional variable, at which point you'd get the standard "didn't unwrap optional" error.

Like I said, I'm not sure this is even possible for compiled code, if the target platform doesn't have hardware support for it anyway.

Sent from my iPhone

> On Jan 28, 2016, at 20:38, Craig Cruden via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>     manager.doSomething(data: data, count: n?)
> 
> What if the return value of doSomething is not an optional?  Expressions are easy — but there might be some conflicts with this one.
> 
> 
>> On 2016-01-28, at 14:34:58, 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> 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> 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>:
>>>>> 
>>>>> Yes
>>>>>> On 2016-01-28, at 12:28:40, Paul Ossenbruggen <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> 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
>>>>>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> 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
> 
> _______________________________________________
> 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/20160129/796c32f9/attachment.html>


More information about the swift-evolution mailing list