[swift-evolution] [Pitch] Tweak `Self` and introduce `Current`
thislooksfun
thislooksfun at repbot.org
Sat Jan 7 11:14:53 CST 2017
I like this idea, however, if I understand the proposal correctly, I think that the naming would make more sense the other way around. `Self` is, at least in my head, tied directly and statically to the enclosing type, where as `Current` sounds more dynamic, and could change from place-to-place.
-thislooksfun (tlf)
> On Jan 7, 2017, at 4:38 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
>
> Hi Swift community,
>
> I’d like to talk to about current Self keyword. If I’m not totally mistaken then the current Self has a few meanings:
>
> Refer to the current type, or refer to the dynamic type for non-final classes inside containing type (SE–0068 - not yet implemented).
> For non-final class types use Self as return type on the conforming super type (or return an instance of receiver Self).
> Let me visualize the behaviors quickly in some short code snippet:
>
> protocol Foo {
> func foo(_ f: Self) -> Self
> }
>
> class A : Foo {
> // forced to use `A` as parameter type and `Self` as return type
> func foo(_ f: A) -> Self { return self }
> // Returning `A()` would cause an error: Cannot convert return expression of type 'A' to return type 'Self'
> func bar() -> A { return A() /* or self */ }
> func zoo() -> Self { return /* only */ self }
> }
>
> class B : A {
> // Both is fine `B` or `Self` as the return type
> // If `B` is used you can return a different instance like `B()`
> // `Self` does only allow `self` to be used here
> override func foo(_ f: A) -> B { return self }
> }
>
> struct D : Foo {
> // No `Self` allowed here at all
> func foo(_ f: D) -> D { return self /* or D() */ }
> }
> The behavior of Self is a little magical, because it sometimes refers to the current type it is used in, or it has a contract of using self.
>
> I propose of introducing a new keyword called Current to solve a few problems here.
>
> Self on parameter types would be disallowed for protocol members, because conformances to that protocol already disallow that (see A above). Instead one would use Current and get the correct meaning.
>
> protocol Boo {
> func boo(_ b: Current) -> Self
> }
>
> procotol Loo {
> func loo() -> Current
> }
>
> class X : Boo, Loo {
> func boo(_ b: X) -> Self { return self }
> func loo() -> X { return self /* or X() */ }
> }
>
> final class Y : Boo {
> func boo(_ b: X) -> Y { return self /* or Y */ }
> }
> Using Self inside the containing type would always mean as one would refer to the dynamic type, like the magical syntax function type(of:) does.
>
> Current can only refer to the current containing type.
>
> On classes Self has always the contract of returning self.
>
> Self could be discouraged in favor of Current on value types, as a shorthand to refer to the containing type.
>
> Generics could benefit from Current too:
>
> extension AReallyLongNonFinalClassName {
> func casted<T : Current>() -> T { ... }
> }
> // `Self` wouldn't here, because it would refer to the dynamic type
> #1 Would affect a lot of protocols which implies that it would affect ABI.
>
> These are the first ideas I had in my mind. We can polish it further if it receives positive and constructive feedback.
>
> Best regards,
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170107/bf63d094/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170107/bf63d094/attachment.sig>
More information about the swift-evolution
mailing list