The only reason I can think of writing a function with a force-unwrapped parameter is overriding an API function with such a signature, as Chris mentioned.
If the function actually doesn’t accept nil you might feel obliged to start the function with something like precondition( IUO argument != nil, “this method cannot handle nil”) in order to at least provide a message rather than just crashing. As for consistency and symmetry I don’t think the current practice meets these criteria. In your own code an IUO means “only use if you are sure it’s non-nil” whereas in imported APIs it means “enter nil at your own risk”. If the unwrap shorthand `if let x!` would be accepted it would mean “if unwrap succeeds use as if it’s an IUO instead of an ordinary optional”. That would make three shades of weirdness. I like it. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
