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

[Ross O'Brien]

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/3fe52689/attachment.html>