on Wed Apr 13 2016, plx <swift-evolution@swift.org> wrote:
> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> on Wed Apr 13 2016, plx
> <swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
