Re: [swift-evolution] $self

Yeah, hard to say how extreme it needs to be to justify this sort of change. Does running into unintentional retain cycles when using closures for event handlers *constantly* count as extreme? :) In a typical garbage collected language, using closures like this is common and a non-issue, but

Re: [swift-evolution] $self

> On Sep 28, 2016, at 7:48 PM, Jay Abbott via swift-evolution > wrote: > > Sean, yeah that's kind of what I was suggesting for @escaping closures - it > should be the default... but it is a breaking change and as Chris pointed out > that would need extreme

Re: [swift-evolution] $self

Sean, yeah that's kind of what I was suggesting for @escaping closures - it should be the default... but it is a breaking change and as Chris pointed out that would need extreme justification... plus it would be a behaviour change with no syntax change, so code that was never "upgraded" would be

Re: [swift-evolution] $self

Now that I think about this, wouldn't that be a better default behavior? All captures are this "required" type which means all closures are typed as optional. To override that behavior, you'd have to explicitly declare a weak or unowned capture instead and if you did that for all reference

Re: [swift-evolution] $self

I think Sean's idea for [required refName] on this is the better one in terms of syntax and clarity of what's going on. It's fairly clear that the required refs are weak but become strong during the closure execution, and that since they're 'required' the closure goes away if they do. In

Re: [swift-evolution] $self

> On Sep 28, 2016, at 4:42 PM, Jay Abbott via swift-evolution > wrote: > > It could potentially be a breaking change if the default for @escaping > closures were made to be weak-capturing. Ok, but source breaking changes need extreme justification. A primary goal

Re: [swift-evolution] $self

Pretty sure this is all way out of scope, but something about this made me think about this idea (which maybe isn't unique or is maybe even unworkable), but imagine something like where a new capture type is added such as "required" (for lack of another name right now). And the way this works

Re: [swift-evolution] $self

It could potentially be a breaking change if the default for @escaping closures were made to be weak-capturing. Since the weak-capturing pattern is only really desirable for @escaping closures, and (I think) it would be the usual preference, could @escaping also imply weak-capturing for all

Re: [swift-evolution] $self

> On Sep 28, 2016, at 4:05 PM, Paul Jack via swift-evolution > wrote: > > So previously there were a few threads on the "strong self/weak self > dance" but they didn't seem to get anywhere. For instance: > >

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

That doesn't look like a variance issue to me, that's about the same "information" invariant I talked about before. The former works because self resolves to an invariant type, the type of the implementing structure, which satisfies the requirement Self introduces. The latter does not because

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

> On Dec 28, 2015, at 11:19 AM, Developer wrote: > > My understanding of Self is that it is a special generic parameter resolved > by the type system to the type of the implementing structure. That > resolution must be invariant because the implementing structure

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

> On Dec 28, 2015, at 8:49 AM, Matthew Johnson via swift-evolution > wrote: > > I have brought up the idea of a non-covarying Self a few times. > > I was surprised to realize that Self is actually non-covarying when used for > parameters in protocol declarations!

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

My understanding of Self is that it is a special generic parameter resolved by the type system to the type of the implementing structure. That resolution must be invariant because the implementing structure (here, non-final classes) can choose to yank the protocol's invariants out from under

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

> On Dec 28, 2015, at 12:04 PM, Developer wrote: > > That doesn't look like a variance issue to me, that's about the same > "information" invariant I talked about before. The former works because self > resolves to an invariant type, the type of the implementing

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

> On Dec 28, 2015, at 12:43 PM, Joe Groff wrote: > >> >> On Dec 28, 2015, at 10:31 AM, Matthew Johnson > > wrote: >> >>> >>> On Dec 28, 2015, at 12:02 PM, Joe Groff >> >

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

> On Dec 28, 2015, at 10:31 AM, Matthew Johnson wrote: > >> >> On Dec 28, 2015, at 12:02 PM, Joe Groff > > wrote: >> >>> >>> On Dec 28, 2015, at 8:49 AM, Matthew Johnson via swift-evolution >>>