> On 9 Nov 2016, at 12:19, Rien <[email protected]> wrote:
>> On 9 Nov 2016, at 06:51, David Hart <[email protected]> wrote:
>>> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution
>>> <[email protected]> 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 😉_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
