> On Jan 7, 2017, at 10:02 AM, Adrian Zubarev via swift-evolution
> wrote:
>
> True, but there are a few edge cases where Self simply does not work.
>
> On classes the return type has the contract to return self.
> Even if we get SE–0068, will Self work in generic context like showed in OP
>
On Sun, Jan 8, 2017 at 4:09 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:
> There are a few good points made here. It’s an interesting workaround to
> use type(of:) to get a similar behavior I wanted. My point is, that
> Current or call it static Self should exist to fill some gaps
There are a few good points made here. It’s an interesting workaround to use
type(of:) to get a similar behavior I wanted. My point is, that Current or call
it static Self should exist to fill some gaps in our design patterns. Using
Self in protocols should not always mean that you shall use the
IMO the most problematic Self becomes in a generic context, i.e.:
(pseudo code below)
protocol Monad {
associatedtype A
func flatMap(f:(A)->Monad) -> ErasedSelf
}
I would really like to have this ErasedSelf.
On Sun, 8 Jan 2017 at 5:21 Xiaodi Wu via swift-evolution <
swift-evolution@swift.org>
On Sat, Jan 7, 2017 at 5:33 PM, Braeden Profile
wrote:
>
>> Of course, I would love being able to use an initializer setup, but there
>> are serious bugs in the implementation.
>>
>> protocol Clonable
>> {
>> init(other: Self)
>> }
>>
>> extension Clonable
>> {
>> func clone() -> Self
>
>
> Of course, I would love being able to use an initializer setup, but there are
> serious bugs in the implementation.
>
> protocol Clonable
> {
> init(other: Self)
> }
>
> extension Clonable
> {
> func clone() -> Self
> { return type(of: self).init(other: self) }
> }
On Sat, Jan 7, 2017 at 4:00 PM, Braeden Profile via swift-evolution <
swift-evolution@swift.org> wrote:
> * One could workaround the problem and use final, but what if the class
> ** meant to be subtypeable? Self simply does not work in this scenario.
> *
> It works exactly as it should in this sc
>
> One could workaround the problem and use final, but what if the class
> meant to be subtypeable? Self simply does not work in this scenario.
>
>
> It works exactly as it should in this scenario. If A isn't final, then by
> definition it's impossible for A to make a copy of type Self. I see
I have no problem with the syntax proposed in SE-0068.
The rationale briefly mentions that dynamic Self will be used anywhere
inside the class body. I think that the possibilities that open with this
decision should be mentioned in the proposal.
We can say that non-final classes, apart from that t
On Sat, Jan 7, 2017 at 12:02 PM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:
> True, but there are a few edge cases where Self simply does not work.
>
>1. On classes the return type has the contract to return self.
>2. Even if we get SE–0068, will Self work in generic context
True, but there are a few edge cases where Self simply does not work.
On classes the return type has the contract to return self.
Even if we get SE–0068, will Self work in generic context like showed in OP
with Current?
#1 Using value semantics on classes means that the returned instance is a new
On Sat, Jan 7, 2017 at 11:34 AM, Xiaodi Wu wrote:
> `Self` _always_ refers to the dynamic type of `self`. It just happens to
> be that in the case of structs the dynamic type is the same as the static
> type. The idea of having a shorthand for the containing type (spelled #Self
> or StaticSelf) w
`Self` _always_ refers to the dynamic type of `self`. It just happens to be
that in the case of structs the dynamic type is the same as the static
type. The idea of having a shorthand for the containing type (spelled #Self
or StaticSelf) was discussed during consideration of SE-0068. The accepted
v
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.
As a naming contrast, one could make Self like the proposed Current, and rename
the current Self to DynamicSelf or something similar.
Most protocols that are meant for value types in first place should use Self
aka. Current as the return type.
--
Adrian Zubarev
Sent with Airmail
Am 7. Janua
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 typ
16 matches
Mail list logo
