How far would you require the compiler to go? precondition(2 < 1)?
precondition(someFunctionThatAlwaysReturnsFalse())?
precondition(isFermatsLastTheoremTrue())?
Just “false”. Why would you write anything else?
Why would you write anything else than preconditionFailure()??
Everyone knows about “false” but not everyone knows about preconditionFailure().
···
On Feb 18, 2016, at 4:52 PM, Thorsten Seitz <tseitz42@icloud.com> wrote:
Am 12.02.2016 um 18:26 schrieb Amir Michail via swift-evolution <swift-evolution@swift.org>:
Not everyone knows about precondition() in the first place, so when he finds it he will probably find preconditionFailure(), too. On top of that the autocomplete will show it to him each time he starts to type precondition. Third it is a common pattern to provide a failure function, where one does not have to supply a false argument, e.g. In unit test assertions.
-Thorsten
···
Am 18.02.2016 um 23:21 schrieb Amir Michail <a.michail@me.com>:
On Feb 18, 2016, at 4:52 PM, Thorsten Seitz <tseitz42@icloud.com> wrote:
Am 12.02.2016 um 18:26 schrieb Amir Michail via swift-evolution <swift-evolution@swift.org>:
How far would you require the compiler to go? precondition(2 < 1)?
precondition(someFunctionThatAlwaysReturnsFalse())?
precondition(isFermatsLastTheoremTrue())?
Just “false”. Why would you write anything else?
Why would you write anything else than preconditionFailure()??
Everyone knows about “false” but not everyone knows about preconditionFailure().
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@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@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > On Feb 12, 2016, at 9:27 AM, Amir Michail<a.michail@me.com(mailto: > a.michail@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@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
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@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@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@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > On Feb 12, 2016, at 9:27 AM, Amir Michail<a.michail@me.com(mailto:a.michail@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@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>