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

[demedeckie at gmail.com]

Well you have described it perfectly. :)
It is indeed default: fatalError() and default: break in one character. 

On the other hand I have fear that we will overwhelm language semantic with ! and ? everywhere. 

So, do you think this ability to tweak compiler behavior and save one line of code is valuable?

Will be interesting to see some statistics  of using different default cases.  

> 13 февр. 2016 г., в 20:36, Ross O'Brien <narrativium+swift at gmail.com> написал(а):
> 
> So...
> 
> Our basic 'switch' takes an expression and tries to match it to the first matching case (with programmer option to 'fallthrough'. The compiler runs an extra routine to check we covered every situation, but as far as I know, it's only sure in cases of booleans and enums. In all other situations the compiler requires a 'default' case.
> 
> The proposed 'switch!' says: the programmer overrules the compiler. Don't require a default case, the provided cases cover everything, yes we're sure, crash if not. It's 'default: fatalError()' in one character.
> 
> I'm not sure what 'switch?' ought to do. If I understand you right, you're suggesting that 'switch?' be 'default: break' in one character. I think that might have merit, but I also think the compiler would still have to do its checks, because in this case:
> 'let x : Foo
> switch? y
> {
>    case z: x = Foo()
>    case ...: ...
>    ...
> }'
> If the compiler doesn't think it can find a matching case for y, then Swift can't be sure that x has a value. That should still have a warning.
> 
> If I haven't understood you, please clarify.
> 
> 
>> On Fri, Feb 12, 2016 at 7:06 PM, Алексей Демедецкий <demedeckie at gmail.com> wrote:
>> +1 for this switch behavior. Can we also treat switch? as one with did not require default checking?
>> 
>> > 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(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
>> >
>> >
>> >
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160213/eb8463d6/attachment.html>