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

[Ross O'Brien]

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.

On Fri, Feb 12, 2016 at 5:45 PM, Amir Michail <a.michail at me.com> wrote:

>
> 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> 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/272fdd6c/attachment.html>