On Thu, Jan 28, 2016 at 10:05 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:
Do you realize how much confusion it would save if Swift just went with
if bind foo = bar {...}
with let semantics?
-- Erica
> On Jan 28, 2016, at 11:03 AM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On Jan 28, 2016, at 12:43 AM, Brent Royal-Gordon < > brent@architechies.com> wrote:
>>
>>> We have a lot of evidence that 'if var' confuses people—a lot of users
think that 'if var' and 'var' bindings in case patterns will write back to
the original value when this isn't the case.
>>
>> Can we address this with a diagnostic?
>>
>> var bar: Int? = 1
>> if var foo = bar {
>> foo += 1 // Warning: Value is never used after
modification (foo is a copy, not an alias)
>> }
>> print(bar)
>
> Good idea.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
Only in conditional binding, to clearly differentiate it from non-conditional binding. One of these things unwraps optionals. One of these does not. They both use the same keyword. It's a stumbling block for a lot of new devs.
And I like where Jacob took it too.
-- E
···
On Jan 28, 2016, at 11:09 AM, Joe Groff <jgroff@apple.com> wrote:
On Jan 28, 2016, at 10:05 AM, Erica Sadun <erica@ericasadun.com> wrote:
Do you realize how much confusion it would save if Swift just went with
if bind foo = bar {...}
with let semantics?
I don't see how changing the keyword changes anything, no.
This is called flow typing in Ceylon and they are using "exists" for that case but testing for conformance with "is" works just the same way there. The latter is of importance because the common use of union types in Ceylon.
if exists foo {
// foo is non-optional here
}
if foo is String {
// foo is of type String here
}
-Thorsten
···
Am 28.01.2016 um 19:08 schrieb Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org>:
On Thu, Jan 28, 2016 at 10:05 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Do you realize how much confusion it would save if Swift just went with
if bind foo = bar {...}
with let semantics?
-- Erica
> On Jan 28, 2016, at 11:03 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
>
>
>> On Jan 28, 2016, at 12:43 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
>>
>>> We have a lot of evidence that 'if var' confuses people—a lot of users think that 'if var' and 'var' bindings in case patterns will write back to the original value when this isn't the case.
>>
>> Can we address this with a diagnostic?
>>
>> var bar: Int? = 1
>> if var foo = bar {
>> foo += 1 // Warning: Value is never used after modification (foo is a copy, not an alias)
>> }
>> print(bar)
>
> Good idea.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
+1 for `bind`. I dislike the use of the same keyword for two different
purposes. Also `if let x = x` is confusing for beginners (by beginners I
mean beginners to Swift not to programming) since:
1. `let x = x` is, outside of binding, an error.
2. Beginners quite rightly say "`x` already equals `x`!".
···
On Friday, 29 January 2016, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:
> On Jan 28, 2016, at 10:05 AM, Erica Sadun <erica@ericasadun.com > <javascript:;>> wrote:
>
> Do you realize how much confusion it would save if Swift just went with
>
> if bind foo = bar {...}
>
> with let semantics?
I don't see how changing the keyword changes anything, no.
That's one reason I'm not a fan of using the same identifier in both
places in these examples. I've usually found the code to be a little
clearer anyway, when I take the time to find a different name.
FWIW-ly y'rs,
···
on Sun Jan 24 2016, David Waite <david-AT-alkaline-solutions.com> wrote:
On Jan 24, 2016, at 6:44 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org> wrote:
On Jan 24, 2016, at 12:31 PM, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > >>> wrote:
That's not the purpose; even though I am not a fan of prohibiting "var"
there, I understand that the purpose of doing so is avoiding confusion,
because some people believe they are getting a reference through which
to mutate the contents of the original optional.
But that’s not what assigning something to a var means in any other
context. Why should it be any different here?
In the case of "if let x = x { … }”, the shadowing/copying of the
original value is not apparent - from the user perspective, the
language just “knows” within the block to stop treating “x” like an
optional.
Perhaps then we should add an “if inout” construct, then, so that the distinction between “inout” and “var” here are clear for people to see, and explained in the documentation?
As a bonus, I can think of a few situations where “if inout” would be useful—particularly so we wouldn’t need the postfix ! to do things like this:
if someStruct.someOptionalArray != nil {
someStruct.someOptionalArray!.append(foo)
}
With “if inout”, you could do this instead:
if inout array = someStruct.someOptionalArray {
array.append(foo)
}
which seems quite a bit cleaner.
Charles
···
On Jan 25, 2016, at 3:54 AM, Quinn The Eskimo! via swift-evolution <swift-evolution@swift.org> wrote:
On 25 Jan 2016, at 03:25, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
On 25 Jan 2016, at 01:44, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:
But that’s not what assigning something to a var means in any other context. Why should it be any different here?
I made the same argument myself, but you can't argue with empirical
evidence: some people have been tripped up by this anyway.
One explanation might be that these folks have a Pascal heritage, where "var" is (roughly) equivalent to Swift's "inout”.
It is true that the proposal seems a bit rushed. Removing ‘var’ in function declarations is a very good move, and I can partially understand its removal in if etc. (even though I disagree that it is that confusing, and its certainly useful as pointed out in this thread), but my biggest gripe is with removal of var in the guard statement. What about a useful pattern like this?
guard var x = SomeOptionalValue() else {
fatalError()
}
x = doSomethingWith(x)
Best,
Taras
···
On 25 Jan 2016, at 10:54, Quinn The Eskimo! via swift-evolution <swift-evolution@swift.org> wrote:
On 25 Jan 2016, at 03:25, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
On 25 Jan 2016, at 01:44, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:
But that’s not what assigning something to a var means in any other context. Why should it be any different here?
I made the same argument myself, but you can't argue with empirical
evidence: some people have been tripped up by this anyway.
One explanation might be that these folks have a Pascal heritage, where "var" is (roughly) equivalent to Swift's "inout".
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
The real issue here is the contrast between reference and value types. What you suggest is basically to introduce a new type to the language: references to values. This type already exists implicitly for the inout parameters. In more simple terms, your example turns into:
if var array = &someStruct.someOptionalArrayl {
array.append(foo)
}
One could expose reference types to the general language instead of keeping it specific to inout arguments only. It might make the language more elegant sometimes. But it might also make it more messy, as it allows one to blur the reference/value distinction deliberately. I really don’t have any opinion right now because I have no idea of what the consequences would be.
But I am certainly against having an ‘inout’ variable declaration modifier. If that is really necessary, than I’d rather see a general reference implementation.
Best,
Taras
···
On 25 Jan 2016, at 13:12, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 25, 2016, at 3:54 AM, Quinn The Eskimo! via swift-evolution <swift-evolution@swift.org> wrote:
On 25 Jan 2016, at 03:25, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
On 25 Jan 2016, at 01:44, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:
But that’s not what assigning something to a var means in any other context. Why should it be any different here?
I made the same argument myself, but you can't argue with empirical
evidence: some people have been tripped up by this anyway.
One explanation might be that these folks have a Pascal heritage, where "var" is (roughly) equivalent to Swift's "inout”.
Perhaps then we should add an “if inout” construct, then, so that the distinction between “inout” and “var” here are clear for people to see, and explained in the documentation?
As a bonus, I can think of a few situations where “if inout” would be useful—particularly so we wouldn’t need the postfix ! to do things like this:
if someStruct.someOptionalArray != nil {
someStruct.someOptionalArray!.append(foo)
}
With “if inout”, you could do this instead:
if inout array = someStruct.someOptionalArray {
array.append(foo)
}
Maybe. Were 'if let' not already drilled into developers' minds, IMO it'd be nice to replace it by 'if case _?'. We had tried that internally and got a lot of backlash though.
-Joe
···
On Jan 28, 2016, at 10:25 AM, Erica Sadun <erica@ericasadun.com> wrote:
Only in conditional binding, to clearly differentiate it from non-conditional binding. One of these things unwraps optionals. One of these does not. They both use the same keyword. It's a stumbling block for a lot of new devs.
This is called flow typing in Ceylon and they are using "exists" for
that case but testing for conformance with "is" works just the same
way there. The latter is of importance because the common use of union
types in Ceylon.
if exists foo {
// foo is non-optional here
}
if foo is String {
// foo is of type String here
}
FWIW, some of us are concerned that if the types of names change
without being announced by a let or var binding, it will be confusing.
That's one reason we haven't gone this way in the past.
···
on Thu Jan 28 2016, Thorsten Seitz <swift-evolution@swift.org> wrote:
-Thorsten
Am 28.01.2016 um 19:08 schrieb Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org>:
On Thu, Jan 28, 2016 at 10:05 AM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org> wrote:
Do you realize how much confusion it would save if Swift just went with
if bind foo = bar {...}
with let semantics?
-- Erica
> On Jan 28, 2016, at 11:03 AM, Joe Groff via swift-evolution >>> > <swift-evolution@swift.org> wrote:
>
>
>> On Jan 28, 2016, at 12:43 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
>>
>>> We have a lot of evidence that 'if var' confuses people—a lot
>>> of users think that 'if var' and 'var' bindings in case
>>> patterns will write back to the original value when this isn't
>>> the case.
>>
>> Can we address this with a diagnostic?
>>
>> var bar: Int? = 1
>> if var foo = bar {
>> foo += 1 // Warning: Value is never used after modification (foo is a copy, not an alias)
>> }
>> print(bar)
>
> Good idea.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
I prefer this style over “if let” & “if var”. I don’t know it is my aversion to “let” because it brings back memories of a language I would prefer to forget (BASIC), but I find the scattering of lets in other statements/expressions to a we bit annoying (especially in pattern matching).
···
On 2016-01-29, at 12:54:12, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:
This is called flow typing in Ceylon and they are using "exists" for that case but testing for conformance with "is" works just the same way there. The latter is of importance because the common use of union types in Ceylon.
if exists foo {
// foo is non-optional here
}
if foo is String {
// foo is of type String here
}
-Thorsten
Am 28.01.2016 um 19:08 schrieb Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
On Thu, Jan 28, 2016 at 10:05 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Do you realize how much confusion it would save if Swift just went with
if bind foo = bar {...}
with let semantics?
-- Erica
> On Jan 28, 2016, at 11:03 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>
>> On Jan 28, 2016, at 12:43 AM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:
>>
>>> We have a lot of evidence that 'if var' confuses people—a lot of users think that 'if var' and 'var' bindings in case patterns will write back to the original value when this isn't the case.
>>
>> Can we address this with a diagnostic?
>>
>> var bar: Int? = 1
>> if var foo = bar {
>> foo += 1 // Warning: Value is never used after modification (foo is a copy, not an alias)
>> }
>> print(bar)
>
> Good idea.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
I think my last response was vague and not in response to this email but I really like this formatting better (though it is probably too late).
If you really want to hack in mutable state in the inner part — then it would be a matter of
if exists foo {
var bar = foo // non-optional
...
}
But I don’t think I would write new code like that anyways.
···
On 2016-01-29, at 12:54:12, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:
This is called flow typing in Ceylon and they are using "exists" for that case but testing for conformance with "is" works just the same way there. The latter is of importance because the common use of union types in Ceylon.
if exists foo {
// foo is non-optional here
}
if foo is String {
// foo is of type String here
}
+1 for `bind`. I dislike the use of the same keyword for two different purposes. Also `if let x = x` is confusing for beginners (by beginners I mean beginners to Swift not to programming) since:
1. `let x = x` is, outside of binding, an error.
2. Beginners quite rightly say "`x` already equals `x`!".
For me, the keyword bind should not be limited to this kind of nil check. but act a bit like an alias. Unfortunately, I cannot come up with nice Swift example; and not sure yet if an aliasing concept is applicable to Swift. For example in C, it is quite common to do:
So that you can use the short name for the heavy work. For read-only operation, the let keyword can be used in that way; but there’s seems to be no easy way if one want to mutate the original data (you are welcome to prove me wrong, my Swiftness is limited)
On the "let x = x" being illegal outside binding, maybe we should make it illegal too for optional binding, especially that the optional binding with var will be reintroduced. This shadowing make it simple when you change your variable from non-optional to optional, as you just wrap the code in the "if let x=x", re-indent the code and voilà; if prohibited one will need to rename all the x by y inside the re-indented code. But such shadowing as its detractor, after all troubles hide in the shadow. But I’ll leave this to be discuss in another thread if someone fells like starting a long and painful discussion, with three battle camps: should allow let x=x, should be an error, should be a warning.
Dany
···
Le 30 janv. 2016 à 20:50, Howard Lovatt via swift-evolution <swift-evolution@swift.org> a écrit :
On Friday, 29 January 2016, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> On Jan 28, 2016, at 10:05 AM, Erica Sadun <erica@ericasadun.com <javascript:;>> wrote:
>
> Do you realize how much confusion it would save if Swift just went with
>
> if bind foo = bar {...}
>
> with let semantics?
I don't see how changing the keyword changes anything, no.
(1) Right now, variable/property declarations always use the word “let” or “var” (with the exception of the for loop iterator). That’s a nice consistency.
(2) It’s not clear on reading whether “bind” means “new declaration” or “alias.” It vaguely suggests I might expect this to work:
let x = 1
bind y = x
y += 10
// x == 11
I do also find “if let” a bit awkward because ungrammatical of it how is — and this is doubly so for “if case” — but I don’t find “if bind" any better on this front. Ultimately, despite their English grammar illogic, “if let” and even “if let x = x” make enough programming language sense that I accepted them, took them as a Swift idioms, and got comfortable with them pretty quickly.
Cheers, P
···
On Jan 30, 2016, at 7:50 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:
+1 for `bind`. I dislike the use of the same keyword for two different purposes. Also `if let x = x` is confusing for beginners (by beginners I mean beginners to Swift not to programming) since:
1. `let x = x` is, outside of binding, an error.
2. Beginners quite rightly say "`x` already equals `x`!".
On Friday, 29 January 2016, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> On Jan 28, 2016, at 10:05 AM, Erica Sadun <erica@ericasadun.com <javascript:;>> wrote:
>
> Do you realize how much confusion it would save if Swift just went with
>
> if bind foo = bar {...}
>
> with let semantics?
I don't see how changing the keyword changes anything, no.
If you all are serious about this, I think you should start a new thread about it.
-Joe
···
On Jan 30, 2016, at 5:50 PM, Howard Lovatt <howard.lovatt@gmail.com> wrote:
+1 for `bind`. I dislike the use of the same keyword for two different purposes. Also `if let x = x` is confusing for beginners (by beginners I mean beginners to Swift not to programming) since:
1. `let x = x` is, outside of binding, an error.
2. Beginners quite rightly say "`x` already equals `x`!".
It's also problematic if 'foo' is mutable, because then it could go from being non-nil to being nil. You could restrict it to constants, but then it doesn't work on instance properties.
Jordan
···
On Jan 29, 2016, at 8:54, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jan 28 2016, Thorsten Seitz <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is called flow typing in Ceylon and they are using "exists" for
that case but testing for conformance with "is" works just the same
way there. The latter is of importance because the common use of union
types in Ceylon.
if exists foo {
// foo is non-optional here
}
if foo is String {
// foo is of type String here
}
FWIW, some of us are concerned that if the types of names change
without being announced by a let or var binding, it will be confusing.
That's one reason we haven't gone this way in the past.
This is called flow typing in Ceylon and they are using "exists" for
that case but testing for conformance with "is" works just the same
way there. The latter is of importance because the common use of union
types in Ceylon.
if exists foo {
// foo is non-optional here
}
if foo is String {
// foo is of type String here
}
FWIW, some of us are concerned that if the types of names change
without being announced by a let or var binding, it will be confusing.
That's one reason we haven't gone this way in the past.
True enough, but is type narrowing (as in the above) really more confusing than
if let x = x {
}
Nothing there suggests that the type of x should change, yet it does. If eliminating confusion was the goal wouldn't
if let x = x? {
}
be more explicit?
Tyler
···
On Jan 29, 2016, at 8:54 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jan 28 2016, Thorsten Seitz <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-Thorsten
Am 28.01.2016 um 19:08 schrieb Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org>:
On Thu, Jan 28, 2016 at 10:05 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org> wrote:
Do you realize how much confusion it would save if Swift just went with
if bind foo = bar {...}
with let semantics?
-- Erica
On Jan 28, 2016, at 11:03 AM, Joe Groff via swift-evolution >>>>> <swift-evolution@swift.org> wrote:
On Jan 28, 2016, at 12:43 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
We have a lot of evidence that 'if var' confuses people—a lot
of users think that 'if var' and 'var' bindings in case
patterns will write back to the original value when this isn't
the case.
Can we address this with a diagnostic?
var bar: Int? = 1
if var foo = bar {
foo += 1 // Warning: Value is never used after modification (foo is a copy, not an alias)
}
print(bar)