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

Amir Michail a.michail at me.com
Fri Feb 12 11:45:04 CST 2016


> On Feb 12, 2016, at 12:41 PM, Ross O'Brien <narrativium+swift at gmail.com> wrote:
> 
> 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.
> 

This doesn’t solve the more general problem — namely, that of required deep knowledge of the standard libraries.

A more general solution would be to provide a way for API writers to issue (heuristic) warnings for suboptimal usage of their APIs.

> 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 <mailto:swift-evolution at swift.org>> wrote:
> On Feb 12, 2016, at 9:27 AM, Amir Michail <a.michail at me.com <mailto: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 <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/b7e26777/attachment.html>


More information about the swift-evolution mailing list