interestingly enough, it looks like a truly simple task... the grammar has 2
types of BindingKind at that location BK_Let and BK_Var, which means that a
single shorthand notation will assume one of the other, which means that if it
does assume one, then it better be explicit about it, or alternatively there
ought to be 2 shorthands for the 2 binding kinds. i.e. :
if unwrapped_var xxxx {
}
and
if unwrapped_let xxxx {
}
or perhaps even easier to express as:
if let! xxxx {
// xxxx is unwrapped LET
}
and
if var! xxxx {
// xxxx is unwrapped VAR
}
>From what I could understand of the compiler, these would seem like localized
>small scale changes, but unfortunately still entirely out of the scope of 3.0
>( not to mention probably still not bringing the clarity chris identified as
>main blocker).
Ideas like this one, that are both simple in scope but out of the main focus
might still be worth collecting somewhere as a series of “if you would like to
get familiar with the compiler codebase to try and help at a future date with
more serious items, we suggest that you look into finding the least intrusive
way to implement any of these features.. we guaranty that there is a simple way
to build them”. They might prove a good training ground for would be helpers.
Apologies for taking your time.
/LM
> On May 17, 2016, at 5:48 PM, Matthew Johnson via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On May 17, 2016, at 10:41 AM, Brandon Knope <bkn...@me.com
>> <mailto:bkn...@me.com>> wrote:
>>
>> I always thought a new keyword made more sense here:
>>
>> if let rebind someValue {
>> //use shadowed unwrapped value in here
>> }
>>
>> if let bind someValue {
>> //use shadowed unwrapped value in here
>> }
>>
>>
>> if let unwrapped someValue {
>>
>> }
>>
>> Something along those lines?
>
> I wouldn’t want to see something like this replace the existing `if let`
> because it doesn’t handle cases where you bind a new name to the result of an
> expression that returns an optional.
>
> If we did consider something like this it would be simple syntactic sugar for
> `if let x = x`. Being syntactic sugar for something that is already not too
> bad means it would need to be as concise as possible. If you want to
> advocate something like this, maybe consider just `if unwrap`:
>
> if unwrap someValue {
> }
>
>
>
>>
>> Brandon
>>
>>
>>> On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> Here’s a idea, what if you could use a symbol to denote that you want the
>>> same name used?
>>>
>>> Here’s an interesting sign from music:
>>> https://en.wikipedia.org/wiki/Repeat_sign
>>> <https://en.wikipedia.org/wiki/Repeat_sign>
>>>
>>> Then you can write (one) of these:
>>>
>>> if let |: = mySomeValue {
>>> // Use unwrapped
>>> }
>>>
>>> if let mySomeValue = :| {
>>> // Use unwrapped
>>> }
>>>
>>> Not sure which one is more clear. Just a totally random idea! I’m not sure
>>> about the above symbols, but it would help in other places too from memory
>>> to not have to write the same variable name twice.
>>>
>>>> On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>>>
>>>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>> While I've sometimes (early on) wished for a shorter-hand syntax for that
>>>>> construct, I've never been able to think of something that I thought was
>>>>> better. I've gotten to the point where I don't particularly mind it
>>>>> anymore.
>>>>>
>>>>> Regarding the exclamation point specifically, seeing one of those in an
>>>>> expression context says to me "this thing will die horribly if it is
>>>>> nil/throws an error". Using it in this context where that's not the case
>>>>> would probably go against users' expectations.
>>>>
>>>> Agree. If we are going have syntax similar to pattern matching it should
>>>> be the same as pattern matching. This would mean using ‘?' rather than
>>>> ‘!’. However, we already have generalized pattern matching with `if case`
>>>> for that. This topic has been debated extensively.
>>>>
>>>>>
>>>>>
>>>>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> On 17.05.2016 16:51, Johan Jensen wrote:
>>>>> > This was one of the first and most commonly suggested ideas, when the
>>>>> Swift
>>>>> > Evolution mailing list first started.
>>>>> > Chris Lattner sums it up
>>>>> >
>>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html
>>>>>
>>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>>
>>>>> > in one of those threads:
>>>>> >
>>>>> >> This is commonly requested - the problem is that while it does help
>>>>> > reduce boilerplate, it runs counter to the goal of improving clarity.
>>>>> >
>>>>> > — Johan
>>>>>
>>>>> Oh, thank you for letting this know.
>>>>>
>>>>> Well, I totally disagree with Chris. And as soon as there was no
>>>>> 'official'
>>>>> proposal and 'official' decision, I'd like to discuss this more.
>>>>>
>>>>> I saw a lot of code like
>>>>> if let mySomeValue = mySomeValue {} in sources and even in books.
>>>>> Plus, I really believe that
>>>>> if let mySomeValue! {..} is better in any way: readability, less space for
>>>>> errors(when you need to repeat the same name) etc
>>>>>
>>>>> FWIW, I suggest more explicit variant:
>>>>> if let value! {...} // with exclamation mark
>>>>> In that "old" proposal there was `if let value {...}`, was not so clear.
>>>>>
>>>>> I can't accept an argument that you can use another name - as usually
>>>>> 'good' name is already 'crafted' for the instance and you want to use it
>>>>> in
>>>>> next code.
>>>>> Otherwise, we need a 'best practice' to name optional variables with some
>>>>> prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
>>>>> mySomeValueOpt` will have a sense. But as I understand, we don't want to
>>>>> use such approach.
>>>>> Additionally, when you shadow optional value with same name - you are
>>>>> *protecting* yourself from using optional value inside block of unwrapped
>>>>> code. IMO it is a good idea.
>>>>> And want we or don't want, we already have this practice widely. So I
>>>>> believe this(my) proposal will improve the code.
>>>>>
>>>>> I'd like to get opinion of the community regarding this feature.
>>>>>
>>>>> On 17.05.2016 16:51, Johan Jensen wrote:
>>>>> > This was one of the first and most commonly suggested ideas, when the
>>>>> > Swift
>>>>> > Evolution mailing list first started.
>>>>> > Chris Lattner sums it up
>>>>> > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html
>>>>> >
>>>>> > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>>
>>>>> > in one of those threads:
>>>>> >
>>>>> >> This is commonly requested - the problem is that while it does help
>>>>> > reduce boilerplate, it runs counter to the goal of improving clarity.
>>>>> >
>>>>> > — Johan
>>>>> >
>>>>> > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
>>>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>
>>>>> > wrote:
>>>>> >
>>>>> > It is common to shadow optional value name with unwrapped value with
>>>>> > same name:
>>>>> >
>>>>> > if let someGoodValue = someGoodValue {...}
>>>>> >
>>>>> > What if we'll have a syntax to not repeat the variable name to
>>>>> > achieve
>>>>> > the same target:
>>>>> >
>>>>> > if let someGoodValue! {...}
>>>>> >
>>>>> > What do you think?
>>>>> > _______________________________________________
>>>>> > swift-evolution mailing list
>>>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> > <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
>>>>> <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
>>>>> <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
>>>> <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
>>> <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
