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

[Amir Michail]

> On Feb 12, 2016, at 12:56 PM, Ross O'Brien <narrativium+swift at gmail.com> wrote:
> 
> Okay, but the original general problem was that you wanted to ensure that one of the cases applied, and my suggestion addressed that problem.
> 
> Since then it's become whether or not the developer has knowledge of fatalError(), preconditionFailure(), and then the more general 'precondition'. It seems to me that the compiler clearly does have some boolean evaluation routine in place, or 'if false { ... }' wouldn't generate the 'this will never be executed' warning I mentioned earlier, and perhaps this routine could be applied to precondition calls as well.
> 
> Providing a way for me to issue warnings for suboptimal use of APIs I write is a third thing entirely.

It would also provide a solution to this problem in particular.

> 
> On Fri, Feb 12, 2016 at 5:45 PM, Amir Michail <a.michail at me.com <mailto:a.michail at me.com>> wrote:
> 
>> On Feb 12, 2016, at 12:41 PM, Ross O'Brien <narrativium+swift at gmail.com <mailto: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/4b5a16dc/attachment.html>