[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