[swift-evolution] [RFC] #Self

[Timothy Wood]

The initial three cases I’d considered were:

1) Textual replacement inside struct/enum/class. This avoids longer boilerplate repetition, making code easier to read and refactor.

2) Default method arguments, like #file and #line, evaluated at the call site, not implementation site. So:

	--- A.swift ---

	class A {
		static func register(_ cls: A.Type = #Self.self)
	}

	--- B.swift ---

	class B : A {
		static func foo() {
			register()
		}
	}

	In this case, the `cls` argument would resolve to B.self (with the ‘.self’ bits possibly not being needed in Swift 3).

3) Adoption points in protocols.

	protocol P {
		static func implementingClass() -> P.Type {
			return #Self.self
		}
	}

	class A : P {}
	class B : A {}

	A.implementingClass() and B.implementingClass() would both return A.self


I suspect that case 1 is the easiest to discuss, but all three make sense to me personally. Perhaps they should be separate proposals, perhaps not. Also, I’m not sure if the implementation would have any ABI/resilience concerns (particularly for #2 and #3 where when crossing module boundaries.

-tim



> On May 10, 2016, at 7:50 AM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
> 
> Quick rundown:
> 
> struct A {
>    ...#Self... // #Self is substituted by A
> }
> 
> class B {
>     ...#Self... // Self is substituted by B
> }
> 
> class C {
>    ... #Self... // Self is substituted by C, which is the defining type at compile time
> }
> 
> I'm stepping away from endorsing or pushing this forward. If you want to pick this up and run with it, it's yours.
> 
> -- E
> 
> 
>> On May 10, 2016, at 8:34 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> Can you clarify where would #Self would be allowed?
>> 
>> * property declarations
>> * method signatures
>> * method and computed property bodies
>> * all of the above
>> 
>> I would like to see this and allowed in all of the above.
>> 
>> We should also consider allowing this in protocol requirements.  It would not covary like Self does for return types, instead being fixed by the class that declares conformance.
>> 
>> Sent from my iPad
>> 
>> On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> To focus SE-0068 and narrow its scope, I removed the `#Self` part of the proposal. This offered compile-time substitution of the defining type for a related #Self literal:
>>> 
>>> A further static identifier, #Self expands to static type of the code it appears within, completing the ways code may want to refer to the type it is declared in. 
>>> 
>>> #Self expands to the static type of the code it is declared within. In value types, this is always the same as Self. In reference types, it refers to the declaring type. #Self will offer a literal textual replacement just like #file, etc.
>>> 
>>> At Chris's suggestion, I'm starting a new SE thread to see whether there remains any interest for including #Self in the language. I'm personally happy with the SE-0068 outcome but I didn't want to undercut anyone like Timothy Wood who had originally spoken up for its inclusion.
>>> 
>>> -- E
>>> 
>>> _______________________________________________
>>> 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/20160510/ebc948ac/attachment.html>