> On 8 Nov 2016, at 12:22, ilya <ilya.nikokos...@gmail.com> 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 <da...@hartbit.com> wrote:
>> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
