[swift-evolution] The bind thread
Erica Sadun
erica at ericasadun.com
Mon Feb 1 16:06:18 CST 2016
Yes, but they don't unwrap. Which is the extra something special.
if let x = x {...}
is kind of really
x.map({f(x)}) // Bless you Kevin!
if you follow what I'm saying. It's not just binding.
-- E
> On Feb 1, 2016, at 2:52 PM, Paul Cantrell <cantrell at pobox.com> wrote:
>
> Pulling & updating my comments from the old thread:
>
>> On Feb 1, 2016, at 1:18 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> The if let x = x {...} and guard let x = x else {...} constructs do something with let (and var) that's fundamentally different from let (and var) elsewhere in the language.
>
> I don’t agree. Wherever they appear, let and var declare a new variable. And they always shadow variables from an outer scope in exactly the same way:
>
> let x = "hi"
> if 3 < 7 {
> let x = ["different", "scope", "different", "x"]
> print(x)
> }
>
> This consistency of meaning for let/var gives the correct implication: “if let” is just a normal variable declaration, even though it appears in the middle of an if condition.
>
>> The same keywords are used to conditionally unwrap
>> and bind an item, not just shadow that item's current value.
>
> In my head, it’s “if”, not “let”, that conveys the conditionality. Really, “if” + “let” is exactly the right combination of concepts; the words just come in a grammatically confusing order.
>
> To me, “bind” misleadingly implies that this is something other than a normal variable declaration: maybe an alias, or a reactive binding, or something like that.
>
> Cheers,
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160201/7537750f/attachment.html>
More information about the swift-evolution
mailing list