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

Ross O'Brien narrativium+swift at gmail.com
Fri Feb 12 11:41:09 CST 2016


I have a suggestion.
Suppose we think of 'switch' as being like a non-optional type. The
compiler does its thing and tries to ensure that the switched expression
will match something, and enforces a default if it cannot verify a matching
state.
Could we force the switch? i.e. suffix the 'switch' keyword with an
exclamation mark, to say: the programmer insists that one of these cases
will match; there's no need for a default case, but if nothing matches then
crash.

For example:
let x:Int
switch! expression
{
    case ... { x = 1 }
    case ... { x = 2 }
    // no default. the ! signifies that the app should crash if none of
these cases matches the expression
}




On Fri, Feb 12, 2016 at 5:32 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> On Feb 12, 2016, at 9:27 AM, Amir Michail <a.michail at me.com> wrote:
> >>>
> >>> What’s wrong with having the compiler explicitly check for “false”?
> >>
> >> Weird special cases make the compiler less predictable.
> >
> > True, but not having them requires deeper knowledge of the standard
> libraries.
> >
> > In practice, just checking for “false” would solve this problem.
>
> That is not what you’re actually proposing.  You are proposing that the
> compiler encode special knowledge of the precondition *library function*
> into the compiler, and teach it about a single special case.  We don’t like
> the compiler to have special cases like this for a large number of reasons,
> in particular, if we did this, someone would file a bug asking for *their*
> equivalent reimplementation of precondition to have the same magic blessed
> behavior.
>
> This is a slippery slope that leads to a lot of complexity downstream, it
> is better to keep the compiler simple and predictable.  Also, as other
> people have pointed out, this has already been solved for you: just use
> preconditionFailure.
>
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/188cc594/attachment.html>


More information about the swift-evolution mailing list