[swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Zach Waldowski]

As much as I favor Swift's preference for API contracts, "I would just
write the code differently," is missing the point of this suggestion.
You can design a single function to look beautiful without any unwraps,
but in a system or a codebase, you must check those preconditions at
some point. If you are dealing with other paradigms that you can't
control, like Cocoa two-stage loading, you must check those
preconditions at some point.
Zach Waldowski
zach at waldowski.me

On Thu, Jun 29, 2017, at 01:43 PM, ilya via swift-evolution wrote:
> I'm not sure those examples are what we should aim for. Generally I
> try to avoid force unwrapping, and specifically in these cases I
> belive a more reliable code would be produced without either ! or the
> !! operators:> 
> https://gist.github.com/ilyannn/4c5530c75293db0324a04f50ae691b2a
> 
> I understand coding styles may differ, but I do worry that we
> "promote" force unwrapping too much by inroducing another
> operator for it.> 
> Ilya.
> 
> 
> On Thu, Jun 29, 2017 at 6:55 PM Erica Sadun via swift-evolution <swift-
> evolution at swift.org> wrote:>> 
>>> On Jun 29, 2017, at 9:13 AM, Dave DeLong <delong at apple.com> wrote:
>>> 
>>> My usage of “!!” generally falls in to two big buckets:
>>> 
>> 
>> I've incorporated all the feedback to date and updated the gist:
>> 
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>> 
>> -- E
>> 
>> 
>> _______________________________________________
>>  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/20170629/3063fcbf/attachment.html>