"cases" adds exhaustiveness and is relatively concise.
Even though it would be nice to have but I don’t think that I would use it frequently.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
···
Can we have a vote on removing / keeping the cases clause. I personally would not typically use it, but there was a split on whether to keep it or delete it so I just kept it in the original until — as I expected — it would be dropped during review (assuming it has a chance of passing).
I though, do not find cases to be particularly hard to read if you have 10 key/value pairs over two lines…. and no mixture….. readability is of the sample in the document is concise in that example and quite readable for me (but I would probably still not use it).
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
···
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
match(1) { cases
1, 3: 10, 2, 4: 20, default: 30
}
There should be a more visible distinction between two "case-item-map" like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
- Maximilian
···
Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen@gmail.com>:
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
I haven't thought of doing it this way This is why these reviews are great. I agree with Craig that, we would not allow commas before the colon. The proposal probably should be updated to make sure that is clear.
Thanks
- Paul
···
Sent from my iPhone
On Feb 4, 2016, at 10:31 AM, Maximilian Hünenberger <m.huenenberger@me.com> wrote:
I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".
match(1) {
case 1, 3: 10
case 2, 4: 20
default: 30
}
// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
match(1) { cases
1, 3: 10, 2, 4: 20, default: 30
}
There should be a more visible distinction between two "case-item-map" like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
- Maximilian
Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen@gmail.com>:
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
cases was added instead of using `cases` because of the potential problems foreseen where the parser would have trouble identifying a list of values.
cases would be restricted to key: value, key: value, key: value and would be considered syntactic sugar that would expand out to
case key1: value1
case key2: value2
case key3: value3
as far as the compilation was concerned.
···
On 2016-02-05, at 1:31:09, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:
I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".
match(1) {
case 1, 3: 10
case 2, 4: 20
default: 30
}
// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
match(1) { cases
1, 3: 10, 2, 4: 20, default: 30
}
There should be a more visible distinction between two "case-item-map" like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
- Maximilian
Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>>:
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
I was playing around with the equivalent case - partial functions in Scala ….
I have known for whatever reason that they would not work within the Scala `reduce` but would work in other functions…. and it bugged me as to why it would work in most but not all (I was wondering if this was some weird implementation limitation).
As far as I can tell, there is a little difference that prevents it. Swift reduce is probably the same as Scala’s foldLeft. I had thought Scala’s reduce is a specialized form of fold but it is not the case.
The difference has to be that Scala’s `reduce` takes a “commutative monoid” — and case partial functions by their very nature [conditions on accumulator or value prevent it] are not commutative in nature — or at least not guaranteed to be so.
Scala’s fold is either left to right, or right to left. `reduce` on the other hand provides no guarantees because it may parallelize it [I am wondering if this is something in common with the concept of big data mapReduce].
···
——
Paul, I will look at updating the proposal to make that clear.
On 2016-02-05, at 4:17:03, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:
I haven't thought of doing it this way This is why these reviews are great. I agree with Craig that, we would not allow commas before the colon. The proposal probably should be updated to make sure that is clear.
Thanks
- Paul
Sent from my iPhone
On Feb 4, 2016, at 10:31 AM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".
match(1) {
case 1, 3: 10
case 2, 4: 20
default: 30
}
// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
match(1) { cases
1, 3: 10, 2, 4: 20, default: 30
}
There should be a more visible distinction between two "case-item-map" like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
- Maximilian
Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>>:
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
match(1) { cases
1, 3: 10, 2, 4: 20, default: 30
}
There should be a more visible distinction between two "case-item-map"
That's why I am against "cases". The visual distinction is nicely provided by "case". No need for something else IMO.
-Thorsten
···
Am 04.02.2016 um 19:31 schrieb Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org>:
like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
- Maximilian
Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen@gmail.com>:
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
Am 04.02.2016 um 19:35 schrieb Craig Cruden <ccruden@novafore.com>:
cases was added instead of using `cases` because of the potential problems foreseen where the parser would have trouble identifying a list of values.
cases would be restricted to key: value, key: value, key: value and would be considered syntactic sugar that would expand out to
case key1: value1
case key2: value2
case key3: value3
as far as the compilation was concerned.
On 2016-02-05, at 1:31:09, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".
match(1) {
case 1, 3: 10
case 2, 4: 20
default: 30
}
// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
match(1) { cases
1, 3: 10, 2, 4: 20, default: 30
}
There should be a more visible distinction between two "case-item-map" like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
- Maximilian
Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>>:
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
The reason is simply that partial functions in Scala are unary function, i.e. take only one argument, while reduce takes a binary function.
I already wrote in another mail why I think that the reduce example in the proposal is problematic, because it does argument splatting.
-Thorsten
···
Am 04.02.2016 um 22:57 schrieb Craig Cruden via swift-evolution <swift-evolution@swift.org>:
Off Topic a little.
I was playing around with the equivalent case - partial functions in Scala ….
I have known for whatever reason that they would not work within the Scala `reduce` but would work in other functions…. and it bugged me as to why it would work in most but not all (I was wondering if this was some weird implementation limitation).
As far as I can tell, there is a little difference that prevents it. Swift reduce is probably the same as Scala’s foldLeft. I had thought Scala’s reduce is a specialized form of fold but it is not the case.
The difference has to be that Scala’s `reduce` takes a “commutative monoid” — and case partial functions by their very nature [conditions on accumulator or value prevent it] are not commutative in nature — or at least not guaranteed to be so.
Scala’s fold is either left to right, or right to left. `reduce` on the other hand provides no guarantees because it may parallelize it [I am wondering if this is something in common with the concept of big data mapReduce].
——
Paul, I will look at updating the proposal to make that clear.
On 2016-02-05, at 4:17:03, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:
I haven't thought of doing it this way This is why these reviews are great. I agree with Craig that, we would not allow commas before the colon. The proposal probably should be updated to make sure that is clear.
Thanks
- Paul
Sent from my iPhone
On Feb 4, 2016, at 10:31 AM, Maximilian Hünenberger <m.huenenberger@me.com> wrote:
I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".
match(1) {
case 1, 3: 10
case 2, 4: 20
default: 30
}
// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
match(1) { cases
1, 3: 10, 2, 4: 20, default: 30
}
There should be a more visible distinction between two "case-item-map" like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
- Maximilian
Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen@gmail.com>:
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
— this works
val r2 = a.foldLeft(0) {
case (acc, x) if x > 4 => println(x); acc + x
case (acc, x) if x <= 4 => acc - x
}
— this does not.
val r3 = a.reduce {
case (acc, x) if x > 4 => println(x); acc + x
case (acc, x) if x <= 4 => acc - x
}
···
On 2016-02-05, at 12:59:06, Thorsten Seitz <tseitz42@icloud.com> wrote:
The reason is simply that partial functions in Scala are unary function, i.e. take only one argument, while reduce takes a binary function.
I already wrote in another mail why I think that the reduce example in the proposal is problematic, because it does argument splatting.
-Thorsten
Am 04.02.2016 um 22:57 schrieb Craig Cruden via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
Off Topic a little.
I was playing around with the equivalent case - partial functions in Scala ….
I have known for whatever reason that they would not work within the Scala `reduce` but would work in other functions…. and it bugged me as to why it would work in most but not all (I was wondering if this was some weird implementation limitation).
As far as I can tell, there is a little difference that prevents it. Swift reduce is probably the same as Scala’s foldLeft. I had thought Scala’s reduce is a specialized form of fold but it is not the case.
The difference has to be that Scala’s `reduce` takes a “commutative monoid” — and case partial functions by their very nature [conditions on accumulator or value prevent it] are not commutative in nature — or at least not guaranteed to be so.
Scala’s fold is either left to right, or right to left. `reduce` on the other hand provides no guarantees because it may parallelize it [I am wondering if this is something in common with the concept of big data mapReduce].
——
Paul, I will look at updating the proposal to make that clear.
On 2016-02-05, at 4:17:03, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I haven't thought of doing it this way This is why these reviews are great. I agree with Craig that, we would not allow commas before the colon. The proposal probably should be updated to make sure that is clear.
Thanks
- Paul
Sent from my iPhone
On Feb 4, 2016, at 10:31 AM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".
match(1) {
case 1, 3: 10
case 2, 4: 20
default: 30
}
// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
match(1) { cases
1, 3: 10, 2, 4: 20, default: 30
}
There should be a more visible distinction between two "case-item-map" like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
- Maximilian
Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>>:
That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.
Sent from my iPhone
On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I still vote for keeping "cases"
I see it as a replacement for dictionary literal "pattern matching":
[1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
Even though it would be nice to have but I don’t think that I would use it frequently.
Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.