SE-0003 Removing var from Function Parameters and Pattern Matching

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

Excellent news. Thanks to the relearn for the special case treatment of the issue and for the comprehensive breakdown.

···

Sent from my iPhone, please excuse brevity and errors

On Jan 28, 2016, at 9:41 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the swift-evolution discussion thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

+3 from me — one for each of the conclusions. This sounds exactly right.

If I understand correctly, we now alllmost have a nice language-wide uniformity:

• Anywhere the syntax allows “let” it also allows “var,” and vice versa.
• Where they’re allowed, exactly one of them _must_ appear.

The exception I can think of is for loops, where the iterator variable’s “let” is still implied. (Are there others?) It would be more uniform, I suppose, to require this:

  for let i in 0..<256

…but that just looks intolerably awkward to my eyes.

Cheers, P

···

On Jan 28, 2016, at 11:41 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1, glad to see this revisited. Agree with the new decisions.

···

On Jan 28, 2016, at 11:41 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I'll miss parameter vars a little bit, but the reasoning for removing them is solid. Really glad to see vars remain in patterns. Thanks to the Swift core team for being open to reconsidering this!

Jarod

···

On Jan 28, 2016, at 21:41, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This is great news! Thank you for being willing to reconsider this
proposal. And the explanation given in this email is really great. Even
though I stated earlier that ditching `var` in parameter lists is mildly
annoying, the rationale given here is very compelling. And the reasons
for keeping "var" everywhere else are spot-on too.

-Kevin Ballard

···

On Thu, Jan 28, 2016, at 09:41 PM, Chris Lattner via swift-evolution wrote:

The core team met to discuss SE-0003, and we have a new conclusion,
described below. As was mentioned on the other thread, this proposal
is a bit unusual because it predates Swift open source, and thus
didn’t go through the full evolution process, nor did it get the
normal public review that would come with it.

The core team broke this proposal down into a few different cases,
each of which came to a different conclusion. To be clear up front,
this is not a clear-cut topic, and there are opinions on all sides.
Here are the decisions the core team came to, along with some
rationale:

*Parameter Lists*

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real
  confusion occurs for some people learning swift that expect “var” to
  provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let”
  nor “var” really make sense there. Parameters were patterns in a
  much older swift design, but that was eliminated a long time ago and
  this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation
  detail being foisted on the interface to the function. To be fair,
  we already have this with "API names" vs "internal names”, but this
  is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and
“let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some
minor boilerplate (the shadowing copy), however, the cost benefit
tradeoff doesn’t pay enough to keep it.

*Patterns*

"if var”, “for var”, "if case var" etc all use the pattern grammar
(aka "pattern matching" and “destructuring” features described in
TSPL). We discussed whether to eliminate var from this, with much
more mixed results:

- We currently have a duality across the language between var and let
  which is common, unifying, and works really well in practice.
  Eliminating var from pattern matching would make the language less
  uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value
  semantics means, and “var x = y” is always a copy of the value. As
  such, based on the strong duality mentioned above, it is reasonable
  to expect people to learn that “if var x = y” produces a copy and
  not a reference binding.

- There certainly is confusion from people who expect “if var” to do a
  reference binding, despite the comment directly above. However, we
  feel that this is more of a point-in-time confusion than the
  parameter case, given that the parameter case exposes the ‘var’ as
  part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let”
in patterns.

*Case Patterns*

We had an additional discussion focused specifically on whether it
would make sense to ban var in case patterns, e.g.: case .Foo(var x):

- The core team agrees that this specific case is a common point of
  confusion, particularly because Swift doesn’t provide a way to get a
  mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less
  regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change
  'let' to 'var' to make it mutable” note that the compiler produces
  for patterns.

Eliminating the note allows users sufficiently knowledgable about
Swift to keep using it, but people who just mash the “fixit” button to
silence the compiler won’t get surprising behavior.

-Swift Core Team

_________________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 :-) Thank the team for the decision and guidance.

···

On Friday, January 29, 2016, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion,
described below. As was mentioned on the other thread, this proposal is a
bit unusual because it predates Swift open source, and thus didn’t go
through the full evolution process, nor did it get the normal public review
that would come with it.

The core team broke this proposal down into a few different cases, each of
which came to a different conclusion. To be clear up front, this is not a
clear-cut topic, and there are opinions on all sides. Here are the
decisions the core team came to, along with some rationale:

*Parameter Lists*

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real
confusion occurs for some people learning swift that expect “var” to
provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor
“var” really make sense there. Parameters were patterns in a much older
swift design, but that was eliminated a long time ago and this aspect never
got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail
being foisted on the interface to the function. To be fair, we already
have this with "API names" vs "internal names”, but this is a bigger
semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let”
from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor
boilerplate (the shadowing copy), however, the cost benefit tradeoff
doesn’t pay enough to keep it.

*Patterns*

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka
"pattern matching" and “destructuring” features described in TSPL). We
discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let
which is common, unifying, and works really well in practice. Eliminating
var from pattern matching would make the language less uniform, because
patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value
semantics means, and “var x = y” is always a copy of the value. As such,
based on the strong duality mentioned above, it is reasonable to expect
people to learn that “if var x = y” produces a copy and not a reference
binding.

- There certainly is confusion from people who expect “if var” to do a
reference binding, despite the comment directly above. However, we feel
that this is more of a point-in-time confusion than the parameter case,
given that the parameter case exposes the ‘var’ as part of the function
signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in
patterns.

*Case Patterns*

We had an additional discussion focused specifically on whether it would
make sense to ban var in case patterns, e.g.:
case .Foo(var x):

- The core team agrees that this specific case is a common point of
confusion, particularly because Swift doesn’t provide a way to get a
mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change
'let' to 'var' to make it mutable” note that the compiler produces for
patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to
keep using it, but people who just mash the “fixit” button to silence the
compiler won’t get surprising behavior.

-Swift Core Team

+1 Awesome News

···

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

A.M.A.Z.I.N.G.

Thanks for letting us know!

R+

···

On 29 Jan 2016, at 06:41, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Huge +1 from me. Thanks!

-Thorsten

···

Am 29.01.2016 um 06:57 schrieb Nate Birkholz via swift-evolution <swift-evolution@swift.org>:

Excellent news. Thanks to the relearn for the special case treatment of the issue and for the comprehensive breakdown.

Sent from my iPhone, please excuse brevity and errors

On Jan 28, 2016, at 9:41 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

A very reasonable decision! It is also good to know that accepted proposals are not “absolute” but will be reviewed again if necessary.

— Taras

···

On 29 Jan 2016, at 07:20, Paul Cantrell via swift-evolution <swift-evolution@swift.org> wrote:

+3 from me — one for each of the conclusions. This sounds exactly right.

If I understand correctly, we now alllmost have a nice language-wide uniformity:

• Anywhere the syntax allows “let” it also allows “var,” and vice versa.
• Where they’re allowed, exactly one of them _must_ appear.

The exception I can think of is for loops, where the iterator variable’s “let” is still implied. (Are there others?) It would be more uniform, I suppose, to require this:

  for let i in 0..<256

…but that just looks intolerably awkward to my eyes.

Cheers, P

On Jan 28, 2016, at 11:41 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 This is great!

···

On Jan 28, 2016, at 10:05 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

Huge +1 from me. Thanks!

-Thorsten

Am 29.01.2016 um 06:57 schrieb Nate Birkholz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

Excellent news. Thanks to the relearn for the special case treatment of the issue and for the comprehensive breakdown.

Sent from my iPhone, please excuse brevity and errors

On Jan 28, 2016, at 9:41 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The core team met to discuss SE-0003, and we have a new conclusion, described below. As was mentioned on the other thread, this proposal is a bit unusual because it predates Swift open source, and thus didn’t go through the full evolution process, nor did it get the normal public review that would come with it.

The core team broke this proposal down into a few different cases, each of which came to a different conclusion. To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. Here are the decisions the core team came to, along with some rationale:

Parameter Lists

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor boilerplate (the shadowing copy), however, the cost benefit tradeoff doesn’t pay enough to keep it.

Patterns

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). We discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value semantics means, and “var x = y” is always a copy of the value. As such, based on the strong duality mentioned above, it is reasonable to expect people to learn that “if var x = y” produces a copy and not a reference binding.

- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. However, we feel that this is more of a point-in-time confusion than the parameter case, given that the parameter case exposes the ‘var’ as part of the function signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.

Case Patterns

We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:
  case .Foo(var x):

- The core team agrees that this specific case is a common point of confusion, particularly because Swift doesn’t provide a way to get a mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change 'let' to 'var' to make it mutable” note that the compiler produces for patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to keep using it, but people who just mash the “fixit” button to silence the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1
Ondrej

···

On Fri, Jan 29, 2016 at 8:14 AM, Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote:

A very reasonable decision! It is also good to know that accepted
proposals are not “absolute” but will be reviewed again if necessary.

— Taras

On 29 Jan 2016, at 07:20, Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote:

+3 from me — one for each of the conclusions. This sounds exactly right.

If I understand correctly, we now alllmost have a nice language-wide
uniformity:

• Anywhere the syntax allows “let” it also allows “var,” and vice versa.
• Where they’re allowed, exactly one of them _must_ appear.

The exception I can think of is for loops, where the iterator variable’s
“let” is still implied. (Are there others?) It would be more uniform, I
suppose, to require this:

for let i in 0..<256

…but that just looks intolerably awkward to my eyes.

Cheers, P

On Jan 28, 2016, at 11:41 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion,
described below. As was mentioned on the other thread, this proposal is a
bit unusual because it predates Swift open source, and thus didn’t go
through the full evolution process, nor did it get the normal public review
that would come with it.

The core team broke this proposal down into a few different cases, each of
which came to a different conclusion. To be clear up front, this is not a
clear-cut topic, and there are opinions on all sides. Here are the
decisions the core team came to, along with some rationale:

*Parameter Lists*

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real
confusion occurs for some people learning swift that expect “var” to
provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let” nor
“var” really make sense there. Parameters were patterns in a much older
swift design, but that was eliminated a long time ago and this aspect never
got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail
being foisted on the interface to the function. To be fair, we already
have this with "API names" vs "internal names”, but this is a bigger
semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let”
from parameter lists.

“var” in a parameter list is convenient sugar that defines away some minor
boilerplate (the shadowing copy), however, the cost benefit tradeoff
doesn’t pay enough to keep it.

*Patterns*

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka
"pattern matching" and “destructuring” features described in TSPL). We
discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let
which is common, unifying, and works really well in practice. Eliminating
var from pattern matching would make the language less uniform, because
patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value
semantics means, and “var x = y” is always a copy of the value. As such,
based on the strong duality mentioned above, it is reasonable to expect
people to learn that “if var x = y” produces a copy and not a reference
binding.

- There certainly is confusion from people who expect “if var” to do a
reference binding, despite the comment directly above. However, we feel
that this is more of a point-in-time confusion than the parameter case,
given that the parameter case exposes the ‘var’ as part of the function
signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in
patterns.

*Case Patterns*

We had an additional discussion focused specifically on whether it would
make sense to ban var in case patterns, e.g.:
case .Foo(var x):

- The core team agrees that this specific case is a common point of
confusion, particularly because Swift doesn’t provide a way to get a
mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change
'let' to 'var' to make it mutable” note that the compiler produces for
patterns.

Eliminating the note allows users sufficiently knowledgable about Swift to
keep using it, but people who just mash the “fixit” button to silence the
compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 on all accounts

···

On Fri, Jan 29, 2016 at 3:21 AM Ondrej Barina via swift-evolution < swift-evolution@swift.org> wrote:

+1
Ondrej

On Fri, Jan 29, 2016 at 8:14 AM, Taras Zakharko via swift-evolution < > swift-evolution@swift.org> wrote:

A very reasonable decision! It is also good to know that accepted
proposals are not “absolute” but will be reviewed again if necessary.

— Taras

On 29 Jan 2016, at 07:20, Paul Cantrell via swift-evolution < >> swift-evolution@swift.org> wrote:

+3 from me — one for each of the conclusions. This sounds exactly right.

If I understand correctly, we now alllmost have a nice language-wide
uniformity:

• Anywhere the syntax allows “let” it also allows “var,” and vice versa.
• Where they’re allowed, exactly one of them _must_ appear.

The exception I can think of is for loops, where the iterator variable’s
“let” is still implied. (Are there others?) It would be more uniform, I
suppose, to require this:

for let i in 0..<256

…but that just looks intolerably awkward to my eyes.

Cheers, P

On Jan 28, 2016, at 11:41 PM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote:

The core team met to discuss SE-0003, and we have a new conclusion,
described below. As was mentioned on the other thread, this proposal is a
bit unusual because it predates Swift open source, and thus didn’t go
through the full evolution process, nor did it get the normal public review
that would come with it.

The core team broke this proposal down into a few different cases, each
of which came to a different conclusion. To be clear up front, this is not
a clear-cut topic, and there are opinions on all sides. Here are the
decisions the core team came to, along with some rationale:

*Parameter Lists*

‘var’ in a parameter list is problematic for a number of reasons:

- Parameter lists currently allow both “inout” and “var”, and real
confusion occurs for some people learning swift that expect “var” to
provide reference semantics.

- Parameter lists are not “patterns” in the language, so neither “let”
nor “var” really make sense there. Parameters were patterns in a much
older swift design, but that was eliminated a long time ago and this aspect
never got reconsidered.

- “var” in a parameter list is odd because it is an implementation detail
being foisted on the interface to the function. To be fair, we already
have this with "API names" vs "internal names”, but this is a bigger
semantic implementation detail.

Conclusion: The core team decided that we should REMOVE “var” and “let”
from parameter lists.

“var” in a parameter list is convenient sugar that defines away some
minor boilerplate (the shadowing copy), however, the cost benefit tradeoff
doesn’t pay enough to keep it.

*Patterns*

"if var”, “for var”, "if case var" etc all use the pattern grammar (aka
"pattern matching" and “destructuring” features described in TSPL). We
discussed whether to eliminate var from this, with much more mixed results:

- We currently have a duality across the language between var and let
which is common, unifying, and works really well in practice. Eliminating
var from pattern matching would make the language less uniform, because
patterns wouldn’t align with var/let declarations.

- Working in Swift *demands* that you get an early grasp on what value
semantics means, and “var x = y” is always a copy of the value. As such,
based on the strong duality mentioned above, it is reasonable to expect
people to learn that “if var x = y” produces a copy and not a reference
binding.

- There certainly is confusion from people who expect “if var” to do a
reference binding, despite the comment directly above. However, we feel
that this is more of a point-in-time confusion than the parameter case,
given that the parameter case exposes the ‘var’ as part of the function
signature.

Conclusion: The core team decided that we should KEEP “var” and “let” in
patterns.

*Case Patterns*

We had an additional discussion focused specifically on whether it would
make sense to ban var in case patterns, e.g.:
case .Foo(var x):

- The core team agrees that this specific case is a common point of
confusion, particularly because Swift doesn’t provide a way to get a
mutable binding to the associated value in an enum.

- That said, making a special case for this would make Swift less regular.

Conclusions:
- The core team decided to KEEP “var” here.
- We will stop leading people into it by eliminating the "note: change
'let' to 'var' to make it mutable” note that the compiler produces for
patterns.

Eliminating the note allows users sufficiently knowledgable about Swift
to keep using it, but people who just mash the “fixit” button to silence
the compiler won’t get surprising behavior.

-Swift Core Team

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution