> On Nov 7, 2016, at 2:08 PM, Haravikk <[email protected]> wrote:
>
>
>> On 7 Nov 2016, at 11:58, Charlie Monroe <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> I'd personally not make this automatic, but require explicit action from the
>> developer.
>>
>> In case of nullability, I have previously suggested "nonnil" keyword:
>>
>> let foo: String? = "Hello World"
>> guard nonnil foo else {
>> return
>> }
>>
>> In which way you explicitly request the type narrowing. Or:
>>
>> let foo: Any
>> guard foo as String else {
>> return
>> }
>>
>> I.e. not using "is" which returns a boolean, but using the cast operator,
>> which IMHO makes more sense and prevents from unintentional type narrowing…
>
> Normally I'm a proponent of being more rather than less explicit, but the
> biggest draw of type-narrowing to me is that you're *already* telling the
> type-checker, it's really just confirming what you know automatically.
>
> So if I do:
>
> if foo is String {
> // Do lots of non-string stuff
> (foo as String).somethingStringSpecific
> }
>
> On the last line of the block the type-checker is able to remind me that I
> already know that foo is a String, so I don't need to cast it.
>
> Really when it comes down to it the type-narrowing never takes anything away
> from you; you can always handle the value as a less specific (wider) type if
> you want to, but if you want to treat it like a String because you know it's
> one, then you can do that too.
>
> I'm concerned that if the feature had to be explicit, it would lack
> discoverability, and really the point is almost to get rid of the need to do
> things explicitly when you don't need to. It's like type inference on
> overdrive in a way.
>
>
> I guess I just don't see why you'd think that "guard nonnil foo" is really
> more explicit than "guard foo != nil", in both cases you know that foo can't
> be nil past that point, so is a new keyword really justified?
I'm simply worried a little about unwanted effects and additional compiler
"cleverness". I'd simply much rather opt-in to it using a keyword or a slightly
different syntax. And instead of
if foo is String { ... }
I'd prefer
if foo as? String { ... }
which is syntactically closer to
if let foo = foo as? String { ... }
which is generally what we're after.
Also, it would maintain code compatibility. The current proposal would change
semantics of the code - mostly when comparing to nil.
Xcode's migration is "nice", but I'd like to point out that migration to Swift
3 of my project took 6 hours (!) and I spent almost 2 more days manually
changing what the migrator didn't manage to do on its own. And that was one of
my projects. I really don't want to go through this once more.
Not to mention the already growing non-macOS base of Swift users.
I know now is the time for the last incompatible changes, but are the benefits
of implicit type narrowing so great to warrant this?
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
