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 <[email protected]> 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
> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
