Interesting thoughts! And thanks for the consideration Chris. Just a
couple more thoughts and I’ll drop this :)
Chris, I love the way you put this:
Since code is read more often than it is written, the real goal behind
Swift is to let you write “more readable code” by eliminating boilerplate
and other noise.
In my view, this proposal is aligned with that goal and it’s as much about
readability as anything. I find this first example so much more readable at
a glance, and I consider the duplicate names and equals sign to be in the
boilerplate/noise category:
if let thing, otherThing, moreThings where thing > 0 { }
if let thing = thing, otherThing = otherThing, moreThings = moreThings where thing > 0 { }
Kevin, in regard to this:
Furthermore, to anyone not already familiar with the proposed rule, `if
let foo {` is meaningless
I agree with David in that the existing syntax is already at the point
where your statement is also true. There is nothing in the current syntax
that indicates that you are unwrapping the optional. It’s only through
learning or familiarity with other languages that one understands it. The =
indicates assignment, but the unwrapping is learned and specific to that
context. The jump to this seems super easy to grok.
Also my point isn’t that it’s doing the same thing technically, but that
it’s a similar concept — assigning to a constant with the value derived
implicitly by the context instead of directly through ‘=‘.
The idea of another keyword like “when” also seems plausible to me, though
it’s a much more drastic change.
On Dec 3, 2015, at 8:13 PM, Sean Heber <sean@fifthace.com> wrote:
What about lifting the whole concept out of "if" or "guard" and making a
new construct that directly communicates the intent?
For example:
when foo { ... }
Which could be combined with "where" to generate an if-like construct:
when foo where foo.isSomething { ... }
Inside the code block, you can access foo directly and it isn't shadowed -
so if it was a var, it is mutable, etc.
l8r
Sean
On Dec 3, 2015, at 8:25 PM, David Waite <david@alkaline-solutions.com> > wrote:
I might argue that if let is already an odd case; people often read it
equivalent to "if (let x=x)”, but “let x=x” has completely different
behavior outside the context of an if let statement (I in fact had to try
it before I realized it does, in fact, work). Obviously, 'let x=x’ on its
own could not have the same behavior.
In that spirit, I propose an alternative feature:
if foo? { … }
where the variable is not shadowed by a copy - instead, inside the block
it behaves as an implicit unwrapped optional, including keeping any
mutability.
so for example:
func foo(x:Int?) {
if var x = x { // var so it can be assigned
x++
}
print(x)
}
foo(1) // => 1, updating the aliased x does not do anything
# working code in Swift 1.2
func bar(x:Int?) {
var y=x
if let x=x {
y=x+1
}
print(y)
}
bar(1) # => Optional(2)
# proposed
func proposed(x:Int?) {
var y = x // since swift 3 won't have var function arguments
if y? { // var so it can be assigned
y++
}
print(y)
}
proposed(1) // => Optional(2)
-DW
On Dec 3, 2015, at 3:42 PM, Chris Lattner <clattner@apple.com> wrote:
“if let foo {“ is a frequently proposed extension to the syntax, but it is
not one that we’re likely to ever add.
I agree that this is a common pattern, and it would allow you to “write
less code”, but that isn’t the goal of Swift. Since code is read more
often than it is written, the real goal behind Swift is to let you write
“more readable code” by eliminating boilerplate and other noise.
Reducing syntax isn’t itself a goal, particularly if the result
could/would be confusing for someone who has to read and maintain your code
later.
-Chris
_______________________________________________
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
