[swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams]

on Wed Apr 13 2016, plx <swift-evolution at swift.org> wrote:

>     On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution
>     <swift-evolution at swift.org> wrote:
>
>     on Wed Apr 13 2016, plx
>     <swift-evolution at swift.org> wrote:
>
>     Seriously, just because Swift has Optionals and they're useful for
>     safety in some scenarios (compared with allowing everything to be
>     nullable) does not mean that it's going to be “Swiftier” to apply a
>     similar pattern everywhere.
>
> This reminds me of something I was going to ask about earlier and forgot. 
>
> Coming from other languages, I’ve definitely brought with me an assumption that
> “make invalid states unrepresentable (except where unavoidable)” is the right
> way to go, with deviations from that rule requiring scrutiny.
>
> Is that outlook actually something the core team considers “Swift-y” or not,
> though? 

That seems very consistent with our outlook.  

Note, however, that a nil optional does not represent an invalid state.
An invalid state is one in which locally-known invariants are broken.
When I say 

     let a = Int("foobaz")

and a is nil, that's a valid representation of the fact that "foobaz"
doesn't parse as an Int.

Part of what this comes down to is whether you're willing to call some
uses of an API wrong (i.e. impose preconditions).  Some people are very
reluctant to do that, but I am not.  It benefits both efficiency and the
ability to reason about code.

> The connection to the point you’re making here and the question is that adopting
> this design style *will* lead to lots of optionals in lots of places.
>
>         use an enum to reintroduce that value when necessary—than to `!`.
>
>         I don’t think the above is an *improvement* over the proposal, but it’s
>         a route
>         that could have been taken.
>
>     I believe it would be hard to make such a design work at all, and if you
>     could make it work I think you'd end up with exactly the problem this
>     proposal aims to solve: references inside indices. So, I don't think
>     it's even a possibility, really.
>
>         To help illustrate the claim, here’s a strawman “safe” API—for
>         illustration
>         only, not advocacy!—that would be safer and thus perhaps more “Swift-y”:
>
>         I think there's a prevalent misunderstanding (IOW, I don't mean to
>         single out this post or this poster) about what “safe” means in Swift
>         and what the features of a Swifty API are and should be. This
>         is a big topic worthy of much more time than I can devote here, but
>         here's a thought to start with:
>
>         A Swifty API helps you reason effectively about the correctness of your
>         code, and in part that means we provide enough preconditions on
>         arguments to avoid complicating result types, and code to handle
>         results, with optional-ness.
>
>         -- 
>         Dave
>
>         _______________________________________________
>         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
>
>     -- 
>     Dave
>
>     _______________________________________________
>     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

-- 
Dave