> On Jun 29, 2017, at 12:23 PM, Djura Retired Hunter via swift-evolution > <[email protected]> wrote: > > >> Il giorno 29 giu 2017, alle ore 19:05, Erica Sadun via swift-evolution >> <[email protected] <mailto:[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.
This is getting off on a tangent, but the interface I wrote for my TableViewController does that. However Since it is a subclass of NS/UIViewController, the `childViewControllers` property is public and directly mutable by anyone. Thus, the assertion that the class is not being misused. Dave > > 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: > <http://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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
