[swift-evolution] [Proposal] Type Narrowing

[Charlie Monroe]

> On Nov 7, 2016, at 2:08 PM, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>> On 7 Nov 2016, at 11:58, Charlie Monroe <charlie at charliemonroe.net <mailto:charlie at charliemonroe.net>> 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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161107/db7313c8/attachment.html>