[swift-evolution] [Proposal] Type Narrowing

[Rien]

I get narrowing, and have admittedly often wished for it myself. Hence I have kept out of this discussion.
But the argument for cognitive overload is imo convincing.

When we create examples, there is almost no (or even negative) cognitive load associated with narrowing.
However when you get a piece of code in front of you with 10+ optionals, 5 if-statements deep with loops intermixed, and you have to find where the nil-error occurs?
It would drive me nuts… especially in these kind of cases:

if foo != nil {
	…
	foo = newFoo()
	…
	if foo != nil {
	…
	}
}

Mind you, I am against automagic narrowing because I like things to be simple, but it is not a make or break deal.

Btw, I think that using a keyword makes it more palatable.

if unwrap foo {
	…
	foo = newFoo()
	…
	if unwrap foo {
	…
	}
}

Now it is clear that something is done to foo, its no longer a compare with side effects but an operation on foo itself.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 09 Nov 2016, at 15:28, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>> On 9 Nov 2016, at 12:19, Rien <Rien at balancingrock.nl> wrote:
>>> On 9 Nov 2016, at 06:51, David Hart <david at hartbit.com> wrote:
>>>> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> This looks like a lot of complexity for very little gain.
>>>> 
>>>> Aside from any implementation concerns, this proposal substantially increases the cognitive load on developers. To figure out what a piece of code means, someone reading it will have to mentally keep track of a “type stack” for every variable. That is the opposite of “clarity at the point of use”.
>>>> 
>>>> Very well said. I think this is perhaps the number one complaint I have about the proposal.
>>> 
>>> Did you see my response to this? There should be no particular cognitive load increase; think of the feature like type inference, the idea here is that the type-checker is gaining the same knowledge that you already have, i.e- you know something isn't nil, so the type-checker should too.
>> 
>> Locally in short routines yes.
>> But in larger modules and non-local this does not apply.
> 
> I'm not sure what you mean; type-narrowing doesn't occur across scopes, ultimately you will always have some starting type where the variable was declared as a property, function argument or local variable, and it is narrow only where it is used, and the narrowing only occurs within that scope for as long as it is relevant.
> 
> In other words, the narrowing is always local. If you know your method takes an optional string for example then you know that that variable is still an optional string throughout that method, type-narrowing just helps to guarantee that it is nil or non-nil where you expect it to be.
> 
>> Imo it should always be possible to look at a type declaration and -from that- derive all necessary knowledge about the type.
> 
> As I say, narrowing never changes the type; if you have a variable with a declared type of Foo, that is narrowed to Bar, then it is because Bar extends Foo and thus is compatible with it, giving you access to any additional methods of Bar without interfering with what you know of Foo.
> 
>> Besides when using a narrowed type as a parameter for an optional it must be automatically be widened again? hence you would mentally keep track of the status of that variable.
> 
> I'm not sure I follow this question; do you mean something like this:
> 
> 	func someMethod(foo:Foo?) {
> 		var bar:Foo? = nil // bar is Optional<Foo>.none
> 		if (foo != nil) { // foo is Optional<Foo>.some
> 			bar = foo // both foo and bar are Optional<Foo>.some
> 		}
> 		// both foo and bar are Optional<Foo> (alternative branch places no mutual guarantee on type)
> 		if bar != nil { // bar is Optional<Foo>.some
> 			bar.someMutatingMethod()
> 		}
> 	}
> 
> But these are all things that the developer knows; bar can't be non-nil until a value for it is set, foo is definitely non-nil within the block etc. The only difference here is that instead of the developer having to use ! unnecessarily (or risk making a mistake) they can just use their knowledge of what it is to interact directly, as the type-checker will now also know the same thing.
> 
> However, with the Optional<T> to T method shadowing issue it seems we probably will need to require a keyword, or at the very least restrict automatic narrowing to polymorphism. For optionals the code will have to look something like this:
> 
> 	func someMethod(foo:Foo?) {
> 		var bar:Foo? = nil
> 		if unwrap foo {
> 			bar = foo
> 		}
> 
> 		if unwrap bar {
> 			bar.someMutatingMethod()
> 		}
> 	}
> 
> The difference here is that unlike shadowing (if let foo = foo), if foo were mutable then it could still be mutated directly, no need to do it with force unwrapping. Of course in these simple examples you could just use the question mark operator instead, but pretend we're doing more than one thing per conditional 😉