Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 19, 2016, at 3:14 AM, L. Mihalkovic > wrote: > > It strikes me that in a sense, the proposed StaticSelf is basically what '_' > does > > By specifying StaticSelf we are trying to tell the compiler to ignore what is > going on that

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

It strikes me that in a sense, the proposed StaticSelf is basically what '_' does By specifying StaticSelf we are trying to tell the compiler to ignore what is going on that that precise location to revert to something expressed 'earlier'. This is somehwat anologous to what we do when we use

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Geeat solution! Thanks to Nicola for posting it! > Am 14.05.2016 um 16:35 schrieb Matthew Johnson via swift-evolution > : > > >> On May 14, 2016, at 12:55 AM, Nicola Salmoria via swift-evolution >> wrote: >> >> Matthew Johnson via

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Oh yep, I accidentally read that section as ‘Alternatives Considered’. I still find this a little bit of a hack, so I hope this approach doesn’t get used too much, certainly not in the standard library. Is this only useful for factory or other static methods? It would just be a shame to see

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 18, 2016, at 9:57 PM, Patrick Smith wrote: > > I think the distinction between StaticSelf and Self will be very confusing to > newcomers. > > So the only reason why we must use StaticSelf instead of Self here is because > we want NSURL to

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I think the distinction between StaticSelf and Self will be very confusing to newcomers. So the only reason why we must use StaticSelf instead of Self here is because we want NSURL to conform, and it isn’t final? protocol StringCreatable { static func createWithString(s: String) ->

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

As a wrap-up of the topic, I've updated our original draft with Nicola S's resolution. https://gist.github.com/erica/995af96a0de2f2f3dc419935e8140927 -- E > On May 14, 2016, at 8:35 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On May 14, 2016, at

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I'm not quite sure I understand the 'Additional Utility' section. A given class hierarchy can only have one implementation of a given static method; static methods are effectively final. Therefore, the 'Self' introduced in the previous proposal should be completely sufficient for invoking a

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Hmm.. very interesting.. @Matthew, is the code below looks like the same as you wanted to achieve with `->StaticSelf` ? protocol Makable { associatedtype MadeType func make(value: Int) -> MadeType } class A { } class B: A { func make(value: Int) -> B { return B() }

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Matthew Johnson via swift-evolution writes: > I agree it’s a bit tricky.  But that’s better than not possible at all.  You just need a typealias and a same type constraint to make this work as expected / desired: > > > protocol Makable { > > typealias RootMakable =

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 3:12 PM, Joe Groff wrote: > >> >> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: >> >> >>> On May 13, 2016, at 10:55 AM, Joe Groff wrote: >>> >>> On May 13, 2016, at 8:18 AM, Matthew Johnson

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: > > >> On May 13, 2016, at 10:55 AM, Joe Groff wrote: >> >> >>> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: >>> >>> When I write a class Base with non-final

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 1:11 PM, Nicola Salmoria via swift-evolution > wrote: > > > > On Fri, May 13, 2016 at 12:55 PM, Vladimir.S > wrote: > > I'm not convinced by this example. > > Probably my & Matthew's previous

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 9:22 AM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On May 13, 2016, at 11:08 AM, Joe Groff wrote: >> >> >>> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: >>> >>> > On May 13,

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 13, 2016, at 11:08 AM, Joe Groff wrote: > > >> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: >> >> On May 13, 2016, at 10:39 AM, Joe Groff wrote: On May 13, 2016, at 8:18

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: > > >> On May 13, 2016, at 10:39 AM, Joe Groff wrote: >> >>> >>> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: >>> >>> >>> >>> Sent from my iPad >>> >>> On May

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 10:55 AM, Joe Groff wrote: > > >> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: >> >> When I write a class Base with non-final methods that return instances of >> Base I can choose whether to state the return type as Self

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 10:39 AM, Joe Groff wrote: > >> >> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >> On May 12, 2016, at 9:21 PM, Joe Groff wrote: >> >>> On May 12, 2016, at

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On May 12, 2016, at 9:21 PM, Joe Groff wrote: > >> >>> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 1:45 AM, Patrick Smith via swift-evolution > wrote: > > Could protocol Self change to just the first behaviour for classes? > > If a conformance absolutely needs to have a method returning ‘only me but not > my subclasses’, then it sets that

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 1:26 AM, David Hart wrote: > > Totally agree. It feels weird to have protocols decide on how "Self" > conformance a are inherited. It should a decision for the conforming type. Do you have any suggestions on how we allow the conforming type to make

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 12, 2016, at 9:21 PM, Joe Groff wrote: > > >> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution >> wrote: >> >> The invariant StaticSelf identifier will always refer to A, unlike Self, >> which is

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

After all these discussions, and after I found out *for myself* what does the proposed `->StaticSelf` in protocol mean, I'm giving my strong +1 to this proposal. This will be a good and useful in some cases language feature, that will add flexibility to Swift. Also it will help to make the

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Am 13. Mai 2016 um 09:36 schrieb "Vladimir.S via swift-evolution" : Why did you decide to drop the `#` ? As `StaticSelf` will be resolved on compilation time like #file etc ? I feel like this is inconsistent solution. # is not needed just like it is not needed for

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 13, 2016, at 8:37 AM, Thorsten Seitz via swift-evolution > wrote: > > Comments inline. > >> Am 13. Mai 2016 um 09:31 schrieb "Vladimir.S via swift-evolution" >> : >> >> I don't feel that InvariantSelf

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Comments inline. Am 13. Mai 2016 um 09:31 schrieb "Vladimir.S via swift-evolution" : I don't feel that InvariantSelf reflects the fact that class conformed to protocol with `f()->InvariantSelf` requirement will actually return 'self or some base class'. Especially

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 1:26 PM, Vladimir.S wrote: > > I don't understand. > Right now we are allowed to have Optional(Self) : > > protocol A { > func g()->Self? > } > > class B: A { > func g()->Self? {return self} > } > > print(B().g()) //Optional(main.B) > > How do you

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I don't understand. Right now we are allowed to have Optional(Self) : protocol A { func g()->Self? } class B: A { func g()->Self? {return self} } print(B().g()) //Optional(main.B) How do you want to divide your `->Self?` and this currently possible `->Self?` ? But I do like the idea

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

The other advantage of Self! over StaticSelf is that in code completion, Self, Self? Self! Will come together, giving people a quick tool to discover/remind themselves of the semantic difference right at the point of use. It might also address Joe's comment about StaticSelf not being much of

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Considering the precedent of using ! and ? in swift, could it be that: Self! would designate what is known for sure, the invariant compile time type of self Self? Would designate the yet unknown (*optional* if you will) covariant type of self Regards LM (From mobile) > On May 13, 2016, at

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

On 13.05.2016 9:45, Patrick Smith wrote: Could protocol Self change to just the first behaviour for classes? If a conformance absolutely needs to have a method returning ‘only me but not my subclasses’, then it sets that conforming method to be final. Hm.. Do we *need* to change `->Self`

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> I'm not convinced by this example. Probably my & Matthew's previous discussion in `[swift-evolution] [RFC] #Self` topic will help you. I was trying there to find out (in primitive examples) what Matthew is trying to achive with this `->StaticSelf` in protocol. In two words - he wants to

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

That makes sense to me. > On May 13, 2016, at 2:45 AM, Patrick Smith via swift-evolution > wrote: > > If a conformance absolutely needs to have a method returning ‘only me but not > my subclasses’, then it sets that conforming method to be final.

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I would prefer BaseSelf. > On May 13, 2016, at 2:28 AM, Vladimir.S via swift-evolution > wrote: > > via ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Matthew Johnson via swift-evolution writes: > Consider the following example, under the current system: > protocol StringCreatable { > static func createWithString(s: String) -> Self > } > > extension NSURL: StringCreatable { > // cannot conform because NSURL is

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Why did you decide to drop the `#` ? As `StaticSelf` will be resolved on compilation time like #file etc ? I feel like this is inconsistent solution. Also, do you expect this will work: protocol A { func g()->StaticSelf } class B: A { func g()->StaticSelf {return B()} } class C: B {

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I don't feel that InvariantSelf reflects the fact that class conformed to protocol with `f()->InvariantSelf` requirement will actually return 'self or some base class'. Especially when this `InvariantSelf` means `exactly this concrete static type name` inside type declaration. Probably the

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

How about BaseType? (as just `Type` can not be used here) Or ThisType? And, do you think we actually should use `#` here in analogue to #file as this `StaticSelf` will be pre-processed on compilation stage to be replaced with actual type name? On 13.05.2016 5:21, Joe Groff via

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Could protocol Self change to just the first behaviour for classes? If a conformance absolutely needs to have a method returning ‘only me but not my subclasses’, then it sets that conforming method to be final. > On 13 May 2016, at 4:38 PM, Vladimir.S wrote: > > The

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

In this case I propose to call it BaseType (or BaseSelf) as actually this 'thing' in meaning `->StaticSelf` means 'self or any base class' On 13.05.2016 7:56, Thorsten Seitz via swift-evolution wrote: +1 Good description of the motivating problem! As for bikeshedding: ConformingSelf,

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Totally agree. It feels weird to have protocols decide on how "Self" conformance a are inherited. It should a decision for the conforming type. > On 13 May 2016, at 04:21, Joe Groff via swift-evolution > wrote: > > >> On May 12, 2016, at 5:49 PM, Matthew Johnson

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

+1 Good description of the motivating problem! As for bikeshedding: ConformingSelf, ConformingType, BaseSelf, BaseType -Thorsten > Am 13.05.2016 um 02:49 schrieb Matthew Johnson via swift-evolution > : > > Erica Sadun and I have written a proposal are following up

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I didn’t really understand some of the lead in discussion examples regarding protocols A and B each being interwoven, but I would prefer to see StaticSelf only used for concrete types, and protocols only to use Self. If Self has problems with non-final classes, then maybe how it works in

[swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Erica Sadun and I have written a proposal are following up the recent discussion thread "[RFC] #Self” with a proposal to introduce StaticSelf, an invariant Self. The recent discussion can be found here: http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565