I'd agree with Doug, completely out of scope. The only way I'd support
a goto statement was to jump to another switch case as in C#.
L
···
On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:
On Jul 11, 2016, at 4:49 PM, Chris Lattner <clattner@apple.com> wrote:
As for all of the other additive changes, I would strongly prefer you to
*wait* on even proposing or discussing these things until after the Swift
3.0 evolution cycle is done. Not only is it distracting for the community,
but the core team and many others won’t be be able to even read the thread
or the responses, thus your discussion cycle will be lacking key input.
On this topic, we specifically discussed this when labeled breaks were being
designed, and when they were expanded to “do” in Swift 2. We specifically
decided to allow break but not continue, because we didn’t want these
control flow statements to be “another way to spell a loop”.
-Chris
So I can take it as a given that this is out of scope for Swift 3 too?
Given patterns A, B, C, and D, suppose a value x matches A, C, and D, whereas another value y matches B and D, and a third value matches B and C. When evaluating x, y, or z, which statements are executed in the following switch statement? How many of these reach the default case? What happens if I append `fallthrough` at the end of case D? What happens if I move case B after case D? (Yes, I know it is possible to figure it out [my understanding of the answer to the first question is appended below], but I hope you'll agree with me that this is much more difficult to decipher than any switch statement that's currently possible.)
```
switch x /* or y, or z */ {
case A:
// ...
continue
case B:
// ...
if C ~= x /* or y, or z, whichever is switched over */ {
continue
}
fallthrough
I'd say it would be fair to disallow continue and fallthrough to occur in the same clause
···
On Jul 10, 2016, at 10:16 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
case C:
// ...
if B ~= x /* or y, or z, whichever is switched over */ {
continue
}
case D:
// ...
default:
// ...
}
```
Given patterns A, B, C, and D, suppose a value x matches A, C, and D,
whereas another value y matches B and D, and a third value matches B and
C. When evaluating x, y, or z, which statements are executed in the
following switch statement? How many of these reach the default case? What
happens if I append `fallthrough` at the end of case D? What happens if I
move case B after case D? (Yes, I know it is possible to figure it out [my
understanding of the answer to the first question is appended below], but I
hope you'll agree with me that this is much more difficult to decipher than
any switch statement that's currently possible.)
```
switch x /* or y, or z */ {
case A:
// ...
continue
case B:
// ...
if C ~= x /* or y, or z, whichever is switched over */ {
continue
}
fallthrough
I'd say it would be fair to disallow continue and fallthrough to occur in
the same clause
Why should `fallthrough` be prohibited but implicit `break` become
mandatory in such a clause? If `continue` were to be implemented in this
context, I'd want the full power of the keyword, including being allowed to
`continue` conditionally, `continue` with different labels, and round out
the case if no conditions are satisfied with either `fallthrough` or
`break` (or, for that matter, `return`, etc.).
···
On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun <erica@ericasadun.com> wrote:
On Jul 10, 2016, at 10:16 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
case C:
// ...
if B ~= x /* or y, or z, whichever is switched over */ {
continue
}
case D:
// ...
default:
// ...
}
```
Starting to know Erica, I think it was a joke, not to be taken seriously :)
···
On 12 Jul 2016, at 18:07, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
I'd agree with Doug, completely out of scope. The only way I'd support
a goto statement was to jump to another switch case as in C#.
L
On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote:
On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote:
On Jul 11, 2016, at 4:49 PM, Chris Lattner <clattner@apple.com> wrote:
As for all of the other additive changes, I would strongly prefer you to
*wait* on even proposing or discussing these things until after the Swift
3.0 evolution cycle is done. Not only is it distracting for the community,
but the core team and many others won’t be be able to even read the thread
or the responses, thus your discussion cycle will be lacking key input.
On this topic, we specifically discussed this when labeled breaks were being
designed, and when they were expanded to “do” in Swift 2. We specifically
decided to allow break but not continue, because we didn’t want these
control flow statements to be “another way to spell a loop”.
-Chris
So I can take it as a given that this is out of scope for Swift 3 too?
I’d love to see goto in Swift, but on the other hand, do {} with labels have so far been sufficient for any practical problem I encountered so far. Goto is much more useful in languages like C, which lack nested functions and other abstraction mechanisms.
Of course, I wouldn’t try to write a high-performance interpreter in Swift any time soon.
— T
···
On 12 Jul 2016, at 18:07, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
I'd agree with Doug, completely out of scope. The only way I'd support
a goto statement was to jump to another switch case as in C#.
L
On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote:
On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote:
On Jul 11, 2016, at 4:49 PM, Chris Lattner <clattner@apple.com> wrote:
As for all of the other additive changes, I would strongly prefer you to
*wait* on even proposing or discussing these things until after the Swift
3.0 evolution cycle is done. Not only is it distracting for the community,
but the core team and many others won’t be be able to even read the thread
or the responses, thus your discussion cycle will be lacking key input.
On this topic, we specifically discussed this when labeled breaks were being
designed, and when they were expanded to “do” in Swift 2. We specifically
decided to allow break but not continue, because we didn’t want these
control flow statements to be “another way to spell a loop”.
-Chris
So I can take it as a given that this is out of scope for Swift 3 too?
I do not understand. `break` is already implicit unless no other code is used.
case something:
if condition { continue }
// ends here. the compiler knows not to go forward and it's not an empty clause
case somethingElse:
`fallthrough` means "ignore the next case statement and execute its clause".
-- E
···
On Jul 10, 2016, at 10:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
On Jul 10, 2016, at 10:16 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
Given patterns A, B, C, and D, suppose a value x matches A, C, and D, whereas another value y matches B and D, and a third value matches B and C. When evaluating x, y, or z, which statements are executed in the following switch statement? How many of these reach the default case? What happens if I append `fallthrough` at the end of case D? What happens if I move case B after case D? (Yes, I know it is possible to figure it out [my understanding of the answer to the first question is appended below], but I hope you'll agree with me that this is much more difficult to decipher than any switch statement that's currently possible.)
```
switch x /* or y, or z */ {
case A:
// ...
continue
case B:
// ...
if C ~= x /* or y, or z, whichever is switched over */ {
continue
}
fallthrough
I'd say it would be fair to disallow continue and fallthrough to occur in the same clause
Why should `fallthrough` be prohibited but implicit `break` become mandatory in such a clause? If `continue` were to be implemented in this context, I'd want the full power of the keyword, including being allowed to `continue` conditionally, `continue` with different labels, and round out the case if no conditions are satisfied with either `fallthrough` or `break` (or, for that matter, `return`, etc.).
I know how it works. Why would you say that it's reasonable to prohibit
fallthrough when continue is used? The difference between it and break is
that Swift chooses the latter to be implied, and obviously we cannot
prohibit break.
···
On Sun, Jul 10, 2016 at 23:51 Erica Sadun <erica@ericasadun.com> wrote:
On Jul 10, 2016, at 10:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun <erica@ericasadun.com> > wrote:
On Jul 10, 2016, at 10:16 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
Given patterns A, B, C, and D, suppose a value x matches A, C, and D,
whereas another value y matches B and D, and a third value matches B and
C. When evaluating x, y, or z, which statements are executed in the
following switch statement? How many of these reach the default case? What
happens if I append `fallthrough` at the end of case D? What happens if I
move case B after case D? (Yes, I know it is possible to figure it out [my
understanding of the answer to the first question is appended below], but I
hope you'll agree with me that this is much more difficult to decipher than
any switch statement that's currently possible.)
```
switch x /* or y, or z */ {
case A:
// ...
continue
case B:
// ...
if C ~= x /* or y, or z, whichever is switched over */ {
continue
}
fallthrough
I'd say it would be fair to disallow continue and fallthrough to occur in
the same clause
Why should `fallthrough` be prohibited but implicit `break` become
mandatory in such a clause? If `continue` were to be implemented in this
context, I'd want the full power of the keyword, including being allowed to
`continue` conditionally, `continue` with different labels, and round out
the case if no conditions are satisfied with either `fallthrough` or
`break` (or, for that matter, `return`, etc.).
I do not understand. `break` is already implicit unless no other code is
used.
case something:
if condition { continue }
// ends here. the compiler knows not to go forward and it's not an
empty clause
case somethingElse:
`fallthrough` means "ignore the next case statement and execute its
clause".
I’d love to see goto in Swift, but on the other hand, do {} with labels have so far been sufficient for any practical problem I encountered so far. Goto is much more useful in languages like C, which lack nested functions and other abstraction mechanisms.
Of course, I wouldn’t try to write a high-performance interpreter in Swift any time soon.
*Sigh*.
Erica was making a joke. There shall be no ‘goto’ in Swift.
- Doug
···
On Jul 12, 2016, at 9:20 AM, Taras Zakharko <taras.zakharko@uzh.ch> wrote:
— T
On 12 Jul 2016, at 18:07, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
I'd agree with Doug, completely out of scope. The only way I'd support
a goto statement was to jump to another switch case as in C#.
L
On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote:
On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org> wrote:
On Jul 11, 2016, at 4:49 PM, Chris Lattner <clattner@apple.com> wrote:
As for all of the other additive changes, I would strongly prefer you to
*wait* on even proposing or discussing these things until after the Swift
3.0 evolution cycle is done. Not only is it distracting for the community,
but the core team and many others won’t be be able to even read the thread
or the responses, thus your discussion cycle will be lacking key input.
On this topic, we specifically discussed this when labeled breaks were being
designed, and when they were expanded to “do” in Swift 2. We specifically
decided to allow break but not continue, because we didn’t want these
control flow statements to be “another way to spell a loop”.
-Chris
So I can take it as a given that this is out of scope for Swift 3 too?
There is some truth in every joke ;) I do like goto though. It makes my C code cleaner and easier to maintain. But given that Swift already has a very reasonable restricted goto mechanism with labels, I am as happy as it gets :)
— T
···
On 12 Jul 2016, at 18:21, Douglas Gregor <dgregor@apple.com> wrote:
On Jul 12, 2016, at 9:20 AM, Taras Zakharko <taras.zakharko@uzh.ch> wrote:
I’d love to see goto in Swift, but on the other hand, do {} with labels have so far been sufficient for any practical problem I encountered so far. Goto is much more useful in languages like C, which lack nested functions and other abstraction mechanisms.
Of course, I wouldn’t try to write a high-performance interpreter in Swift any time soon.
*Sigh*.
Erica was making a joke. There shall be no ‘goto’ in Swift.
- Doug
— T
On 12 Jul 2016, at 18:07, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
I'd agree with Doug, completely out of scope. The only way I'd support
a goto statement was to jump to another switch case as in C#.
L
On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution >>> <swift-evolution@swift.org> wrote:
On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org> wrote:
On Jul 11, 2016, at 4:49 PM, Chris Lattner <clattner@apple.com> wrote:
As for all of the other additive changes, I would strongly prefer you to
*wait* on even proposing or discussing these things until after the Swift
3.0 evolution cycle is done. Not only is it distracting for the community,
but the core team and many others won’t be be able to even read the thread
or the responses, thus your discussion cycle will be lacking key input.
On this topic, we specifically discussed this when labeled breaks were being
designed, and when they were expanded to “do” in Swift 2. We specifically
decided to allow break but not continue, because we didn’t want these
control flow statements to be “another way to spell a loop”.
-Chris
So I can take it as a given that this is out of scope for Swift 3 too?
Because one says "consider the next case" and the other says "do not consider the next case"
···
On Jul 10, 2016, at 11:03 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
I know how it works. Why would you say that it's reasonable to prohibit fallthrough when continue is used? The difference between it and break is that Swift chooses the latter to be implied, and obviously we cannot prohibit break.
On Sun, Jul 10, 2016 at 23:51 Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
On Jul 10, 2016, at 10:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
On Jul 10, 2016, at 10:16 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
Given patterns A, B, C, and D, suppose a value x matches A, C, and D, whereas another value y matches B and D, and a third value matches B and C. When evaluating x, y, or z, which statements are executed in the following switch statement? How many of these reach the default case? What happens if I append `fallthrough` at the end of case D? What happens if I move case B after case D? (Yes, I know it is possible to figure it out [my understanding of the answer to the first question is appended below], but I hope you'll agree with me that this is much more difficult to decipher than any switch statement that's currently possible.)
```
switch x /* or y, or z */ {
case A:
// ...
continue
case B:
// ...
if C ~= x /* or y, or z, whichever is switched over */ {
continue
}
fallthrough
I'd say it would be fair to disallow continue and fallthrough to occur in the same clause
Why should `fallthrough` be prohibited but implicit `break` become mandatory in such a clause? If `continue` were to be implemented in this context, I'd want the full power of the keyword, including being allowed to `continue` conditionally, `continue` with different labels, and round out the case if no conditions are satisfied with either `fallthrough` or `break` (or, for that matter, `return`, etc.).
I do not understand. `break` is already implicit unless no other code is used.
case something:
if condition { continue }
// ends here. the compiler knows not to go forward and it's not an empty clause
case somethingElse:
`fallthrough` means "ignore the next case statement and execute its clause".
Right. Both seem equally reasonable alternatives if a condition isn't
fulfilled where I'd like to continue pattern matching. Why do you say one
of these would be fair to disallow?
···
On Mon, Jul 11, 2016 at 00:39 Erica Sadun <erica@ericasadun.com> wrote:
Because one says "consider the next case" and the other says "do not
consider the next case"
On Jul 10, 2016, at 11:03 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
I know how it works. Why would you say that it's reasonable to prohibit
fallthrough when continue is used? The difference between it and break is
that Swift chooses the latter to be implied, and obviously we cannot
prohibit break.
On Sun, Jul 10, 2016 at 23:51 Erica Sadun <erica@ericasadun.com> wrote:
On Jul 10, 2016, at 10:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun <erica@ericasadun.com> >> wrote:
On Jul 10, 2016, at 10:16 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
Given patterns A, B, C, and D, suppose a value x matches A, C, and D,
whereas another value y matches B and D, and a third value matches B and
C. When evaluating x, y, or z, which statements are executed in the
following switch statement? How many of these reach the default case? What
happens if I append `fallthrough` at the end of case D? What happens if I
move case B after case D? (Yes, I know it is possible to figure it out [my
understanding of the answer to the first question is appended below], but I
hope you'll agree with me that this is much more difficult to decipher than
any switch statement that's currently possible.)
```
switch x /* or y, or z */ {
case A:
// ...
continue
case B:
// ...
if C ~= x /* or y, or z, whichever is switched over */ {
continue
}
fallthrough
I'd say it would be fair to disallow continue and fallthrough to occur
in the same clause
Why should `fallthrough` be prohibited but implicit `break` become
mandatory in such a clause? If `continue` were to be implemented in this
context, I'd want the full power of the keyword, including being allowed to
`continue` conditionally, `continue` with different labels, and round out
the case if no conditions are satisfied with either `fallthrough` or
`break` (or, for that matter, `return`, etc.).
I do not understand. `break` is already implicit unless no other code is
used.
case something:
if condition { continue }
// ends here. the compiler knows not to go forward and it's not an
empty clause
case somethingElse:
`fallthrough` means "ignore the next case statement and execute its
clause".
I'm saying pick behavior A or behavior B but don't do A & B because that makes computing the possibilities unnecessarily complex and I cannot think of a single real-world use-case where one would want to do both at the same time.
-- E
···
On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
Right. Both seem equally reasonable alternatives if a condition isn't fulfilled where I'd like to continue pattern matching. Why do you say one of these would be fair to disallow?
I disagree. First, in both cases there's an A and a B. The two scenarios we
are comparing are "if condition continue, else break" and "if condition
continue, else fallthrough". Both break and fallthrough are equally control
transfer experiments. Both of these scenarios add complexity for reasoning
(compare case B and case C in my example above).
Obviously, in code, whichever of statement A or B is first reached will
preclude execution of the other. But the whole point of control flow
statements is to provide an expressive way to branch when necessary. If we
agree that the complexity introduced by `continue` is worthwhile and
useful, then "if condition continue, else fallthrough" is just as
legitimate a use case as "if condition continue, else break."
As such, I'd conclude that I'm neutral on the proposal (I could do without
it, but it would be intriguing and Swifty to empower the switch statement
further). However, if adopted I'd strongly urge having all uses of continue
permitted. Including something like `continue case 0..<2 where y < z` if a
subsequent case is written as such, since after all cases are syntaxed like
labels.
···
On Mon, Jul 11, 2016 at 00:44 Erica Sadun <erica@ericasadun.com> wrote:
> On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> Right. Both seem equally reasonable alternatives if a condition isn't
fulfilled where I'd like to continue pattern matching. Why do you say one
of these would be fair to disallow?
I'm saying pick behavior A or behavior B but don't do A & B because that
makes computing the possibilities unnecessarily complex and I cannot think
of a single real-world use-case where one would want to do both at the same
time.
Can you give me an example where anyone would ever want to say:
case something:
continue
fallthrough
-- E
···
On Jul 10, 2016, at 11:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
I disagree. First, in both cases there's an A and a B. The two scenarios we are comparing are "if condition continue, else break" and "if condition continue, else fallthrough". Both break and fallthrough are equally control transfer experiments. Both of these scenarios add complexity for reasoning (compare case B and case C in my example above).
Obviously, in code, whichever of statement A or B is first reached will preclude execution of the other. But the whole point of control flow statements is to provide an expressive way to branch when necessary. If we agree that the complexity introduced by `continue` is worthwhile and useful, then "if condition continue, else fallthrough" is just as legitimate a use case as "if condition continue, else break."
As such, I'd conclude that I'm neutral on the proposal (I could do without it, but it would be intriguing and Swifty to empower the switch statement further). However, if adopted I'd strongly urge having all uses of continue permitted. Including something like `continue case 0..<2 where y < z` if a subsequent case is written as such, since after all cases are syntaxed like labels.
On Mon, Jul 11, 2016 at 00:44 Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
> On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
>
> Right. Both seem equally reasonable alternatives if a condition isn't fulfilled where I'd like to continue pattern matching. Why do you say one of these would be fair to disallow?
I'm saying pick behavior A or behavior B but don't do A & B because that makes computing the possibilities unnecessarily complex and I cannot think of a single real-world use-case where one would want to do both at the same time.
switch fourSidedShape {
case rhombus:
// do some rhombus-specific work
if parallelogram ~= shape { continue }
// do some other rhombus-specific but parallelogram-inapplicable work
fallthrough
case rhomboid:
// do work the slow way
// applies to all rhomboids including rhombuses unless parallelogram
/* implied break */
default:
// now we're left with parallelograms (including rectangles and squares)
// but in the case of non-rect parallelograms,
// some preparatory work has been done above
// do remaining work the fast way
}
···
On Mon, Jul 11, 2016 at 00:56 Erica Sadun <erica@ericasadun.com> wrote:
On Jul 10, 2016, at 11:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
I disagree. First, in both cases there's an A and a B. The two scenarios
we are comparing are "if condition continue, else break" and "if condition
continue, else fallthrough". Both break and fallthrough are equally control
transfer experiments. Both of these scenarios add complexity for reasoning
(compare case B and case C in my example above).
Obviously, in code, whichever of statement A or B is first reached will
preclude execution of the other. But the whole point of control flow
statements is to provide an expressive way to branch when necessary. If we
agree that the complexity introduced by `continue` is worthwhile and
useful, then "if condition continue, else fallthrough" is just as
legitimate a use case as "if condition continue, else break."
As such, I'd conclude that I'm neutral on the proposal (I could do without
it, but it would be intriguing and Swifty to empower the switch statement
further). However, if adopted I'd strongly urge having all uses of continue
permitted. Including something like `continue case 0..<2 where y < z` if a
subsequent case is written as such, since after all cases are syntaxed like
labels.
On Mon, Jul 11, 2016 at 00:44 Erica Sadun <erica@ericasadun.com> wrote:
> On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> Right. Both seem equally reasonable alternatives if a condition isn't
fulfilled where I'd like to continue pattern matching. Why do you say one
of these would be fair to disallow?
I'm saying pick behavior A or behavior B but don't do A & B because that
makes computing the possibilities unnecessarily complex and I cannot think
of a single real-world use-case where one would want to do both at the same
time.
-- E
Can you give me an example where anyone would ever want to say:
Wouldn't that be served better by `case let (x?, y?) where validate(x) &&
validate(y)` ?
Jacob
···
On Sun, Jul 10, 2016 at 11:39 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:
Or, less contrived, based on code I just wrote today (and refactored,
because this doesn't work today), given two optionals a and b:
let c: Foo?
switch (a, b) {
case let (x?, y?):
if validate(x) && validate(y) {
c = x & y // yes, bitwise and
continue
}
fallthrough
case let (x?, nil):
c = x
case let (nil, y?):
c = y
case let (nil, nil):
c = nil
fallthrough /* or, for that matter, continue */
default:
// other stuff here that needs to be done
// unless c == x or c == y
}
On Mon, Jul 11, 2016 at 1:11 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
switch fourSidedShape {
case rhombus:
// do some rhombus-specific work
if parallelogram ~= shape { continue }
// do some other rhombus-specific but parallelogram-inapplicable work
fallthrough
case rhomboid:
// do work the slow way
// applies to all rhomboids including rhombuses unless parallelogram
/* implied break */
default:
// now we're left with parallelograms (including rectangles and squares)
// but in the case of non-rect parallelograms,
// some preparatory work has been done above
// do remaining work the fast way
}
On Mon, Jul 11, 2016 at 00:56 Erica Sadun <erica@ericasadun.com> wrote:
On Jul 10, 2016, at 11:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
I disagree. First, in both cases there's an A and a B. The two scenarios
we are comparing are "if condition continue, else break" and "if condition
continue, else fallthrough". Both break and fallthrough are equally control
transfer experiments. Both of these scenarios add complexity for reasoning
(compare case B and case C in my example above).
Obviously, in code, whichever of statement A or B is first reached will
preclude execution of the other. But the whole point of control flow
statements is to provide an expressive way to branch when necessary. If we
agree that the complexity introduced by `continue` is worthwhile and
useful, then "if condition continue, else fallthrough" is just as
legitimate a use case as "if condition continue, else break."
As such, I'd conclude that I'm neutral on the proposal (I could do
without it, but it would be intriguing and Swifty to empower the switch
statement further). However, if adopted I'd strongly urge having all uses
of continue permitted. Including something like `continue case 0..<2 where
y < z` if a subsequent case is written as such, since after all cases are
syntaxed like labels.
On Mon, Jul 11, 2016 at 00:44 Erica Sadun <erica@ericasadun.com> wrote:
> On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> Right. Both seem equally reasonable alternatives if a condition isn't
fulfilled where I'd like to continue pattern matching. Why do you say one
of these would be fair to disallow?
I'm saying pick behavior A or behavior B but don't do A & B because
that makes computing the possibilities unnecessarily complex and I cannot
think of a single real-world use-case where one would want to do both at
the same time.
-- E
Can you give me an example where anyone would ever want to say:
Or, less contrived, based on code I just wrote today (and refactored,
because this doesn't work today), given two optionals a and b:
let c: Foo?
switch (a, b) {
case let (x?, y?):
if validate(x) && validate(y) {
c = x & y // yes, bitwise and
continue
}
fallthrough
case let (x?, nil):
c = x
case let (nil, y?):
c = y
case let (nil, nil):
c = nil
fallthrough /* or, for that matter, continue */
default:
// other stuff here that needs to be done
// unless c == x or c == y
}
···
On Mon, Jul 11, 2016 at 1:11 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
switch fourSidedShape {
case rhombus:
// do some rhombus-specific work
if parallelogram ~= shape { continue }
// do some other rhombus-specific but parallelogram-inapplicable work
fallthrough
case rhomboid:
// do work the slow way
// applies to all rhomboids including rhombuses unless parallelogram
/* implied break */
default:
// now we're left with parallelograms (including rectangles and squares)
// but in the case of non-rect parallelograms,
// some preparatory work has been done above
// do remaining work the fast way
}
On Mon, Jul 11, 2016 at 00:56 Erica Sadun <erica@ericasadun.com> wrote:
On Jul 10, 2016, at 11:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
I disagree. First, in both cases there's an A and a B. The two scenarios
we are comparing are "if condition continue, else break" and "if condition
continue, else fallthrough". Both break and fallthrough are equally control
transfer experiments. Both of these scenarios add complexity for reasoning
(compare case B and case C in my example above).
Obviously, in code, whichever of statement A or B is first reached will
preclude execution of the other. But the whole point of control flow
statements is to provide an expressive way to branch when necessary. If we
agree that the complexity introduced by `continue` is worthwhile and
useful, then "if condition continue, else fallthrough" is just as
legitimate a use case as "if condition continue, else break."
As such, I'd conclude that I'm neutral on the proposal (I could do
without it, but it would be intriguing and Swifty to empower the switch
statement further). However, if adopted I'd strongly urge having all uses
of continue permitted. Including something like `continue case 0..<2 where
y < z` if a subsequent case is written as such, since after all cases are
syntaxed like labels.
On Mon, Jul 11, 2016 at 00:44 Erica Sadun <erica@ericasadun.com> wrote:
> On Jul 10, 2016, at 11:42 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> Right. Both seem equally reasonable alternatives if a condition isn't
fulfilled where I'd like to continue pattern matching. Why do you say one
of these would be fair to disallow?
I'm saying pick behavior A or behavior B but don't do A & B because that
makes computing the possibilities unnecessarily complex and I cannot think
of a single real-world use-case where one would want to do both at the same
time.
-- E
Can you give me an example where anyone would ever want to say: