[swift-evolution] [Discussion]: Deprecate !-Unwrapping of Optionals

[Vanderlei Martinelli]

-1 for the deprecation.

-Van

On Mon, Feb 29, 2016 at 9:41 PM, Developer via swift-evolution <
swift-evolution at swift.org> wrote:

> To move the discussion forward, perhaps a better analogy is not pointers,
> but casting.  C++ uses the well-known const_cast, static_cast, and
> reinterpret_cast, primitives as a sin-tax on the usage of casting.  It
> makes a fundamentally unsafe operation incredibly obvious, and makes the
> programmer think twice about asking C++ to violate its internal consistency
> checks in the name of a “leap of logic” made by the programmer.  While it
> is possible to use casting safely, just as it is possible to use bang
> safely, the language makes it clear it doesn’t wish to encourage a bad
> pattern.  Casting didn’t go away here, casting didn’t get “harder”, but
> casting in C++ versus C got syntactically heavier and thus makes the
> programmer pause, if only for a second longer, to consider other options.
>
> > On Feb 29, 2016, at 6:29 PM, Brent Royal-Gordon <brent at architechies.com>
> wrote:
> >
> >> These are equivalent to naked unguarded dereferences in C-like
> languages and are, we can all agree, a code smell, not a feature.
> >
> > I previously wrote a 463-word post in this thread arguing that these are
> *not* code smells. Maybe you don't agree with that position, but if you
> really think "we can all agree" it's a code smell, you're not actually
> listening to the arguments against you.
> >
> > I also object to the idea that these are "unguarded" dereferences. `!`
> *is* guarded by code which always reliably causes a crash if the value is
> nil. If this unwrap is guarded:
> >
> >       guard let foo = foo else {
> >               fatalError("foo is nil!")
> >       }
> >       doSomething(foo)
> >
> > Then so is this:
> >
> >       doSomething(foo!)
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
>
> _______________________________________________
> 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/20160229/61b05fbb/attachment.html>