> On 09 Nov 2016, at 10:51, Haravikk via swift-evolution > <[email protected]> wrote: > > >> On 8 Nov 2016, at 12:22, ilya <[email protected]> wrote: >> >> (1) You can define different methods with the same name on T and Optional<T> >> (description is such an example). Then what does this do? >> >> // someMethod is defined both for T and T? >> // var foo: T? >> if foo != nil { >> foo.someMethod() >> } >> >> I say there is a clear expectation that foo.someMethod() should call the >> method of T?, even inside the if block, since this is how the dot works. >> However, according to the proposal it will call another method (or become an >> error?). >> >> I think the languages that use optional narrowing are the ones where T? is >> not a separate type, so that it cannot have its own methods. > > Hmm, that is definitely a wrinkle in the plan; it's very much an edge case > (someone defining something on optionals that they probably shouldn't) but > not an easy one to resolve. I suppose I'll have to amend the proposal to > suggest type widening in that case, such that you would need to use ! or ? as > normal to specify the unwrapped value. The tricky part is that it means the > value would have to be widened from the start, otherwise you'd be accessing > the value in two different ways in the same block of code, which would mean > that narrowing would need to be blocked if there's an incompatible statement > further down… ugh, perhaps a keyword will be necessary then? I was really > hoping to avoid having to add one though. > >> (2) Should this work? >> >> // compilcatedStuff is a method of T >> // class A { var foo: T? } >> >> if foo != nil { >> foo.compilcatedStuff() >> foo.compilcatedStuff() >> foo.compilcatedStuff() >> } >> >> Suppose the compiler doesn't have enough information about compilcatedStuff >> to know what happens inside. Then it's possible that foo.compilcatedStuff >> will actually change foo (for example, foo could be a relationship and >> compilcatedStuff may be deleting the relationship). So, what is the >> suggestion for this example? Perhaps >> >> if foo != nil { >> foo.compilcatedStuff() >> foo?.compilcatedStuff() >> foo?.compilcatedStuff() >> } >> >> or some other choice? > > What do you imagine being inside .complicatedStuff()? It shouldn't be > possible for it to change foo to nil, as even if .complicatedStuff() > reassigned this, it would be doing so as type T. > >> 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. Imo it should always be possible to look at a type declaration and -from that- derive all necessary knowledge about the type. 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. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
