Although I’m fine with the current behavior I’d go for the explicit init form.
Swift promotes explicit value bindings avoiding surprises which I learnt to 
like.

In Java private Optional<T> var; field declaration without RHS simply gets 
inited with a null value and not the expected “none”. Really annoying.

Gábor




Sent from my iPhone

> On 2017. Nov 8., at 9:06, Slava Pestov via swift-evolution 
> <[email protected]> wrote:
> 
> 
> 
>> On Nov 7, 2017, at 11:22 PM, Howard Lovatt via swift-evolution 
>> <[email protected]> wrote:
>> 
>> Not a big deal either way, but I prefer the 2nd (nil) form and therefore 
>> would like to see the 1st form go. It would make Swift more consistent, 
>> consider:
>> 
>> let o: Int? // Looks like nil is assigned.
>> if someTest {
>>     o = 1 // Why isn't this an error? (OK I know why - but it looks odd.)
>> } else {
>>     o = nil
>> }
>> 
>> 
>> Whilst the above works it is weird because if you are aware that o: Int? 
>> normally assigns nil then the above looks like o, which is a let, is 
>> assigned to twice. If you do the equivalent of the above for a non-optional 
>> it is an error.
> 
> The default initialization behavior is specifically not enabled for let 
> bindings. Compare:
> 
> let x: Int?
> print(x as Any) // error: constant 'x' used before being initialized
> 
> var y: Int?
> print(y as Any)
> 
> So your example is perfectly consistent, because you’re only initializing ‘o’ 
> once (along each control flow path).
> 
> Slava
> 
>> 
>>   -- Howard.
>> 
>>> On 8 November 2017 at 07:54, Adrian Zubarev via swift-evolution 
>>> <[email protected]> wrote:
>>> Same here, but I wouldn’t care much if it were gone.
>>> 
>>> 
>>> Am 7. November 2017 um 21:40:56, David Hart via swift-evolution 
>>> ([email protected]) schrieb:
>>> 
>>>> Yeah, I use the first form constantly.
>>>> 
>>>> > On 6 Nov 2017, at 23:33, Slava Pestov via swift-evolution 
>>>> > <[email protected]> wrote:
>>>> > 
>>>> > Hi all,
>>>> > 
>>>> > Right now, the following two declarations are equivalent:
>>>> > 
>>>> > struct S {
>>>> > var x: Int?
>>>> > }
>>>> > 
>>>> > struct S {
>>>> > var x: Int? = nil
>>>> > }
>>>> > 
>>>> > That is, mutable bindings of sugared optional type (but not 
>>>> > Optional<T>!) always have a default value of ‘nil’. This feature 
>>>> > increases the surface area of the language for no good reason, and I 
>>>> > would like to deprecate it in -swift-version 5 with a short proposal. 
>>>> > Does anyone feel strongly about giving it up? I suspect most Swift users 
>>>> > don’t even know it exists.
>>>> > 
>>>> > Slava
>>>> > _______________________________________________
>>>> > swift-evolution mailing list
>>>> > [email protected]
>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to