> Il giorno 29 giu 2017, alle ore 19:05, Erica Sadun via swift-evolution
> <[email protected]> ha scritto:
>
>
>> On Jun 29, 2017, at 9:13 AM, Dave DeLong <[email protected]
>> <mailto:[email protected]>> 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
> <https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b>
>
> -- E
In my opinion the phrase "An often-touted misconception ... a serious failure."
taken from Ben Cohen's comment should not be included in the proposal because,
other than being a personal opinion, it's a extremely generic statement that
doesn't suggest at all "when" force unwrap is good and it's not useful as a
guideline for people that read this things to learn something. Saying things
like "this is kind of ok but too much of it is wrong" is not useful.
> // in a custom view controller subclass that only accepts children of a
> certain kind:
> let existing = childViewControllers as? Array<TableRowViewController> !!
> "TableViewController must only have TableRowViewControllers as children"
>
In my opinion this example shows very well how you can always switch the need
to force unwrap with a more specific contract for a class, or in other words,
with a more specific type. Instead of referring to childViewControllers, you
could simply have an array of objects of the specific type that mediates the
addition and reference to the underlying "childViewControllers" storage. It
uses the type system to enforce correctness.
Now, I'm NOT saying that force unwrapping is always bad, but adding examples
like these to a official proposal could make people think that force unwrapping
is a perfectly fine thing to do for production code instead of designing types
for safety, and safety enforced with a strong type system IS a cornerstone of
Swift, like it or not, as reported on swift.org/about: "The most obvious way to
write code should also behave in a safe manner. Undefined behavior is the enemy
of safety, and developer mistakes should be caught before software is in
production. Opting for safety sometimes means Swift will feel strict, but we
believe that clarity saves time in the long run.".
Elviro
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
