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 <er...@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 <matt...@anandabits.com
>> <mailto:matt...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
