[swift-evolution] Proposal: Initialization should not be required in precondition(false) case.

[Amir Michail]

> On Feb 12, 2016, at 11:27 AM, Ross O'Brien <narrativium+swift at gmail.com> wrote:
> 
> It would be really helpful if you could describe the problem you're experiencing so I don't have to guess what it is from your example code.
> 

I want to ensure that one of the cases applies. Otherwise, there is a bug in my code. That’s why I have the precondition(false).

However, writing code like this is annoying:

let x:Int
if … { x = 1 }
else if … { x = 2 }
else { x = dummyValue; precondition(false) } 

> Am I guessing right if I say that you want a change to Swift such that a switch initialisation can be 'force-unwrapped', such that if none of the cases apply, the app crashes, in a more explicit fashion?
> 
> I've written code like this, but I've tended towards 'default: fatalError()', which wouldn't be covered by your suggestion. 'precondition' isn't at fault here.
> 
> Just as a digression, I've just learned that 'precondition(false)' doesn't cause any immediately following code to receive the compiler warning 'will never be executed' that code in a 'if false { ... }' does. So that would be nice.
> 
> On Fri, Feb 12, 2016 at 3:59 PM, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> For example:
> 
> let x:Int
> if … { x = 1 }
> else if … { x = 2 }
> else { precondition(false) } // no initialization needed
> 
> Similarly,
> 
> let x:Int
> switch ... {
> case …: x = 1
> case …: x = 2
> default: precondition(false) // no initialization needed
> }
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160212/0f614432/attachment.html>