Ah, OK -- it sounds like we just differ on what would be least confusing =)
The other proposed name of #StaticSelf, seems like it would be very clear (if a bit redundant and longer than needed, once you’ve come across it once or twice). I could certainly live with #StaticSelf.
-tim
···
On May 10, 2016, at 9:28 AM, Matthew Johnson <matthew@anandabits.com> wrote:
Yep, understood. It's perfectly clear to me but I understand why Chris is concerned about it having potential to confuse people. It is a pretty subtle difference especially since Self and self are the same in some contexts. In any case, I would be content to live with any name that wins out.
Self and self are different for non-final classes. In protocol
requirements Self would covary and self would be fixed by the class
that provides conformance. The distinction is pretty subtle and is
Will both variants coexist? I'd prefer compiler to be strict in this case and allows only self in b() method, as this is more correct and explicit declaration, i.e. func b(c: Self) in protocol A really means func b(c: self). No?
Agree.
class C: A { func a() -> Self { return self } func b(c: C) {} // b(c: self) ? }
C is non-final so we must be careful. C and self both refer to the
same thing. Self covaries and would thus refer to the dynamic type of
the instance in both signatures and bodies. This means that a method
returning Self must be overridden by all subclasses in order to return
the correct type.
Yes, I believe it is all clear with a() method. This is why I placed the commend with self for `b` method only
One of the advantages of allowing self in protocol requirements is that
it is one way to solve a problem that has receive significant discussion
on the list in the past: retroactively conforming non-final classes to
protocols with factory methods that do not need to covary. There is no
way to express a this kind of requirement in the language today.
Could you please illustrate this in a couple lines of code? Just to fully understand.
protocol A {
static func createWithString(s: String) -> Self
}
extension NSURL: A {
// cannot conform because NSURL is non-final
}
If we could define a protocol requirement that didn't covary (using self or whatever) we would be able to write the desired conformance.
···
Sent from my iPad
On May 10, 2016, at 11:25 AM, Vladimir.S <svabox@gmail.com> wrote:
On 10.05.2016 18:47, Matthew Johnson wrote:
On May 10, 2016, at 10:34 AM, Vladimir.S via swift-evolution >>> <swift-evolution@swift.org> wrote:
protocol A2 { var a: Self {get} }
final class C2 : A2 { var a: C2 { return C2() } // self { return self() } ? }
In final classes and value types the type name itself (C2 in this
example), Self, and self would all reference the same thing.
Exactly in my example, you can't use `Self` keyword in class:
final class C2 : A2 {
var a: Self { return Self() } // error
}
but I expect to be able to have:
final class C2 : A2 {
var a: self { return self() }
}
On 10.05.2016 17:50, Erica Sadun via swift-evolution 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@anandabits.com <mailto:matthew@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:sw
Another suggestion was StaticSelf. Any opinion on that one? Also, do you think we should just drop the # altogether?
If we find a name we can agree on and there is no significant opposition is this a proposal that could make it into Swift 3? I would be willing to write one if that is the case.
-Matthew
···
On May 10, 2016, at 1:43 PM, Chris Lattner <clattner@apple.com> wrote:
On May 10, 2016, at 9:03 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
That's a fair critique. Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
How about #Type or #StaticType?
Either of those would make more sense to me than using # as a distinguisher for dynamic vs static. This isn’t what we use # for.
As far as I understand self should be the type of the implementor (ImplementorSelf?) or conforming type (ConformingSelf?).
How would this work with default methods?
extension A {
func f() -> self { return init() } // what type has self here?
}
class C : A {}
let c = C().f() // what type has c here?
-Thorsten
···
Am 10.05.2016 um 18:41 schrieb Timothy Wood via swift-evolution <swift-evolution@swift.org>:
On May 10, 2016, at 9:28 AM, Matthew Johnson <matthew@anandabits.com> wrote:
Yep, understood. It's perfectly clear to me but I understand why Chris is concerned about it having potential to confuse people. It is a pretty subtle difference especially since Self and self are the same in some contexts. In any case, I would be content to live with any name that wins out.
Ah, OK -- it sounds like we just differ on what would be least confusing =)
The other proposed name of #StaticSelf, seems like it would be very clear (if a bit redundant and longer than needed, once you’ve come across it once or twice). I could certainly live with #StaticSelf.
As I understand, please correct me, this proposal will not solve this problem. The proposed solution just to introduce self as replacement for concrete name of currently declared type.
And actually I think(I don't understand?) something is wrong with what you want to achieve..
Let's imagine we have non-final class:
class C {
static func f() -> C { return C() }
}
and, as class is not final, we can have subclasses :
class D : C {
}
Now we introduce the protocol:
protocol A {
static func f() -> self // let's imagine self can be in this place
// in test code I used C instead of self here
}
And conform C to A, so this says "C will return C when we call f()"
extension C: A {
// let's imagine it is OK here, C.f() returns self which is C
}
But now, we have a problem with D - as C conforms to protocol A, D also conforms to protocol A :
var c = C()
var d = D()
if c is A {print("c is A")} // c is A
if d is A {print("d is A")} // d is A
But...
print(C.f()) // main.C
print(D.f()) // main.C oops! D.f() does not return its self, i.e. main.D
···
On 10.05.2016 19:37, Matthew Johnson wrote:
Could you please illustrate this in a couple lines of code? Just to
fully understand.
protocol A { static func createWithString(s: String) -> Self }
extension NSURL: A { // cannot conform because NSURL is non-final }
If we could define a protocol requirement that didn't covary (using self or whatever) we would be able to write the desired conformance.
As I understand, please correct me, this proposal will not solve this problem. The proposed solution just to introduce self as replacement for concrete name of currently declared type.
And actually I think(I don't understand?) something is wrong with what you want to achieve..
Let's imagine we have non-final class:
class C {
static func f() -> C { return C() }
}
and, as class is not final, we can have subclasses :
class D : C {
}
Now we introduce the protocol:
protocol A {
static func f() -> self // let's imagine self can be in this place
// in test code I used C instead of self here
}
And conform C to A, so this says "C will return C when we call f()"
extension C: A {
// let's imagine it is OK here, C.f() returns self which is C
}
But now, we have a problem with D - as C conforms to protocol A, D also conforms to protocol A :
var c = C()
var d = D()
if c is A {print("c is A")} // c is A
if d is A {print("d is A")} // d is A
But...
print(C.f()) // main.C
print(D.f()) // main.C oops! D.f() does not return its self, i.e. main.D
No, the whole point is that D.f() returns C because C is the requirement of 'f' is declared to return self which is C where the protocol conformance is declared and implemented. If you want a covariant requirement you would use Self as the return type, not self.
···
Sent from my iPad
On May 10, 2016, at 12:33 PM, Vladimir.S <svabox@gmail.com> wrote:
On 10.05.2016 19:37, Matthew Johnson wrote:
Could you please illustrate this in a couple lines of code? Just to
fully understand.
protocol A { static func createWithString(s: String) -> Self }
extension NSURL: A { // cannot conform because NSURL is non-final }
If we could define a protocol requirement that didn't covary (using self or whatever) we would be able to write the desired conformance.
Yep, understood. It's perfectly clear to me but I understand why Chris is concerned about it having potential to confuse people. It is a pretty subtle difference especially since Self and self are the same in some contexts. In any case, I would be content to live with any name that wins out.
Ah, OK -- it sounds like we just differ on what would be least confusing =)
The other proposed name of #StaticSelf, seems like it would be very clear (if a bit redundant and longer than needed, once you’ve come across it once or twice). I could certainly live with #StaticSelf.
In that case StaticSelf would be sufficient IMHO. The # should only be needed to distinguish between Self and self.
As far as I understand self should be the type of the implementor (ImplementorSelf?) or conforming type (ConformingSelf?).
How would this work with default methods?
extension A {
func f() -> self { return init() } // what type has self here?
}
The conforming type. C in your example. If we have 'class D: C' and it overrides 'f' the override would have a return type of C, not D. The returned instance could be of type D since it is a subtype of C. We could also explore allowing overrides to have a covariant return type, it just wouldn't be visible when accessed via the protocol through a generic constraint or an existential (those would only guarantee C, the type that declared the conformance.
···
Sent from my iPad
On May 10, 2016, at 12:59 PM, Thorsten Seitz <tseitz42@icloud.com> wrote:
Am 10.05.2016 um 18:41 schrieb Timothy Wood via swift-evolution <swift-evolution@swift.org>:
On May 10, 2016, at 9:28 AM, Matthew Johnson <matthew@anandabits.com> wrote:
I haven’t thought about this in depth and completely misunderstood the proposal before :-)
If I understand, this is simply a shortcut to avoid having to spell out the static type name, most useful when copying/pasting code or when the type name is long. That argues for keeping it short (a knock against StaticSelf). Also, I think it would make sense to drop the #: Self doesn’t have it for example, and that is the closest relative.
That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?
-Chris
···
On May 10, 2016, at 12:03 PM, Matthew Johnson <matthew@anandabits.com> wrote:
That's a fair critique. Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
How about #Type or #StaticType?
Either of those would make more sense to me than using # as a distinguisher for dynamic vs static. This isn’t what we use # for.
Another suggestion was StaticSelf. Any opinion on that one? Also, do you think we should just drop the # altogether?
If we find a name we can agree on and there is no significant opposition is this a proposal that could make it into Swift 3? I would be willing to write one if that is the case.
That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?
I would love to see a way to get the type of the "enclosing thing at compile time”. In my particular case, I’m using the type as a generic parameter to tag a created resource with something like:
class Client: PropertyOwner {
let intProperty = Client.property(“name”, Int(0))
}
where PropertyOwner has a static property<Owner, DataType>(...)
With `Self` meaning the static version of the thing being compiled, I could at least write:
class Client: PropertyOwner {
let intProperty = Self.property(“name”, Int(0))
}
which would have the benefit of being harder to mess up due to copy-pasting between different PropertyOwner implementors.
and
I was thinking about the syntax a bit further and it seems like the capability that would be added is like #file, in that it does some compile-time textual replacement. So, perhaps self would work?
Also, along these lines, I would find use for call-site interpolation like #file has. I could then do a free function version of my property() call that was something like:
That's a fair critique. Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
How about #Type or #StaticType?
Either of those would make more sense to me than using # as a distinguisher for dynamic vs static. This isn’t what we use # for.
Another suggestion was StaticSelf. Any opinion on that one? Also, do you think we should just drop the # altogether?
If we find a name we can agree on and there is no significant opposition is this a proposal that could make it into Swift 3? I would be willing to write one if that is the case.
I haven’t thought about this in depth and completely misunderstood the proposal before :-)
If I understand, this is simply a shortcut to avoid having to spell out the static type name, most useful when copying/pasting code or when the type name is long. That argues for keeping it short (a knock against StaticSelf). Also, I think it would make sense to drop the #: Self doesn’t have it for example, and that is the closest relative.
Good point about keeping it short. 'Type' seems like the best candidate.
That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?
The only case where there is new functionality is when this is used in a protocol requirement. I gave an example earlier today.
It also provides a shortcut for verbose type names, although that is relatively unimportant.
···
Sent from my iPad
On May 10, 2016, at 4:01 PM, Chris Lattner <clattner@apple.com> wrote:
On May 10, 2016, at 12:03 PM, Matthew Johnson <matthew@anandabits.com> wrote:
No, the whole point is that D.f() returns C because C is the requirement
of 'f' is declared to return self which is C where the protocol
conformance is declared and implemented. If you want a covariant
requirement you would use Self as the return type, not self.
I just followed your example with NSURL.. Probably I don't understand the point, but you said you want to conform a non-final class to protocol with method -> self.
>---------------------<
protocol A { static func createWithString(s: String) -> Self }
extension NSURL: A { // cannot conform because NSURL is non-final }
If we could define a protocol requirement that didn't covary (using self or whatever) we would be able to write the desired conformance.
>---------------------<
And I don't understand how do you want to achieve the target, as even if we 'invent' self, this (as I understand) can't work as class is not final. Just like with 'simple' Self - class must be final to conform. Thank you for clarification.
No, class would not need to be final to conform to a requirement returning self. The difference is that with Self covaries and self does not. This means you do not need to guarantee that all subclasses override a requirement that returns self, while you do need to guarantee that all subclasses override a requirement that returns Self.
The requirement to guarantee that all subclasses provide this override is the reason you cannot declare conformance in the case of requirements returning Self. Since this isn’t necessary for self (will probably have a different name) the class does not need to be final in order to conform.
-Matthew
···
On May 10, 2016, at 1:38 PM, Vladimir.S <svabox@gmail.com> wrote:
On 10.05.2016 20:50, Matthew Johnson wrote:
No, the whole point is that D.f() returns C because C is the requirement
of 'f' is declared to return self which is C where the protocol
conformance is declared and implemented. If you want a covariant
requirement you would use Self as the return type, not self.
I just followed your example with NSURL.. Probably I don't understand the point, but you said you want to conform a non-final class to protocol with method -> self.
>---------------------<
protocol A { static func createWithString(s: String) -> Self }
extension NSURL: A { // cannot conform because NSURL is non-final }
If we could define a protocol requirement that didn't covary (using self or whatever) we would be able to write the desired conformance.
>---------------------<
And I don't understand how do you want to achieve the target, as even if we 'invent' self, this (as I understand) can't work as class is not final. Just like with 'simple' Self - class must be final to conform. Thank you for clarification.
This functionality is the key: Ability of an open (non-final) class to conform to a protocol that lets it return an instance of the conforming type (itself). Self does not work for that and we can’t change its behavior (or can we?) So one solution seems to be Matt’s proposal. This functionality is important for me and an example use case is class clusters. For the client code it is sealed and acts just like a final class, but internally it may return a subclass that is an implementation detail. We should be able to do this.
Hooman
···
On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?
The only case where there is new functionality is when this is used in a protocol requirement. I gave an example earlier today.
That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?
The only case where there is new functionality is when this is used in a protocol requirement. I gave an example earlier today.
This functionality is the key: Ability of an open (non-final) class to conform to a protocol that lets it return an instance of the conforming type (itself). Self does not work for that and we can’t change its behavior (or can we?) So one solution seems to be Matt’s proposal. This functionality is important for me and an example use case is class clusters. For the client code it is sealed and acts just like a final class, but internally it may return a subclass that is an implementation detail. We should be able to do this.
Agree and this is why I am willing to write the proposal for this. There was a discussion a few months ago about this problem and a few solutions were kicked around. The biggest problem with this approach at the time was lack of a good name, which I believe we now have in Type.
I'm going to let the discussion continue for a day or two and will write a proposal if no significant counter arguments arise.
-Matthew
···
Sent from my iPad
On May 10, 2016, at 5:24 PM, Hooman Mehr <hooman@mac.com> wrote:
On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
That said, I’m not sure I understand the concrete use-cases. When is this
concept important? When is “Self” not good enough?
The only case where there is new functionality is when this is used in a
protocol requirement. I gave an example earlier today.
This functionality is the key: Ability of an open (non-final) class to
conform to a protocol that lets it return an instance of the conforming
type (itself). Self does not work for that and we can’t change its behavior
(or can we?) So one solution seems to be Matt’s proposal. This
functionality is important for me and an example use case is class
clusters. For the client code it is sealed and acts just like a final
class, but internally it may return a subclass that is an implementation
detail. We should be able to do this.
Help me understand this. Maybe an example will help. Why is it a problem to
return the subclass instead of the base class?
···
On Tue, May 10, 2016 at 5:24 PM, Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote:
On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:
That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?
From my old mail on the subject:
I would love to see a way to get the type of the "enclosing thing at compile time”. In my particular case, I’m using the type as a generic parameter to tag a created resource with something like:
class Client: PropertyOwner {
let intProperty = Client.property(“name”, Int(0))
}
where PropertyOwner has a static property<Owner, DataType>(...)
With `Self` meaning the static version of the thing being compiled, I could at least write:
class Client: PropertyOwner {
let intProperty = Self.property(“name”, Int(0))
}
which would have the benefit of being harder to mess up due to copy-pasting between different PropertyOwner implementors.
and
I was thinking about the syntax a bit further and it seems like the capability that would be added is like #file, in that it does some compile-time textual replacement. So, perhaps self would work?
Also, along these lines, I would find use for call-site interpolation like #file has. I could then do a free function version of my property() call that was something like:
which would only be callable from w/in things conforming to or subclassing PropertyOwner.
Ahh, this is different than what I have been talking about as it statically evaluates at the call site rather than the declaration site. Sorry, I think I missed your earlier post.
One question about this - how would it work if this method was called in a lexical con txt without an enclosing type declaration? Would that be an error or would it just require a parameter to be passed?
If we call what I am talking about Type and we also want this behavior we should call it #Type as it would be the static type at the call site. But they are separate ideas and should be separate proposals.
···
Sent from my iPad
On May 10, 2016, at 5:41 PM, Timothy Wood <tjw@me.com> wrote:
On May 10, 2016, at 2:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
No, class would not need to be final to conform to a requirement
returning self. The difference is that with Self covaries and self does not. This means you *do not need* to guarantee that all subclasses override a requirement that returns self, while you do need to guarantee that all subclasses override a requirement that returns Self.
I'm probably slow these day, but I(and probably someone else) just can't understand this. Thank you for your patience in explaining this:
Just after you conforms *base* class to *any* protocol, any possible subclass *must* (you *have to* guarantee this) conform the same protocol.
class A {..}
class B:A {..}
class C:A {..}
protocol D {..}
extension A: D {}
-> now B&C and any other existed and *possible* subclass *must* conforms to the same protocol D just because of inheritance. As soon as they are subclass of A, they *must* be `is D` and *must* have the methods that return self. No?
···
On 10.05.2016 22:04, Matthew Johnson wrote:
On May 10, 2016, at 1:38 PM, Vladimir.S <svabox@gmail.com> wrote:
On 10.05.2016 20:50, Matthew Johnson wrote:
No, the whole point is that D.f() returns C because C is the requirement
of 'f' is declared to return self which is C where the protocol
conformance is declared and implemented. If you want a covariant
requirement you would use Self as the return type, not self.
I just followed your example with NSURL.. Probably I don't understand the point, but you said you want to conform a non-final class to protocol with method -> self.
---------------------<
protocol A { static func createWithString(s: String) -> Self }
extension NSURL: A { // cannot conform because NSURL is non-final }
If we could define a protocol requirement that didn't covary (using self or whatever) we would be able to write the desired conformance.
---------------------<
And I don't understand how do you want to achieve the target, as even if we 'invent' self, this (as I understand) can't work as class is not final. Just like with 'simple' Self - class must be final to conform. Thank you for clarification.
No, class would not need to be final to conform to a requirement returning self. The difference is that with Self covaries and self does not. This means you do not need to guarantee that all subclasses override a requirement that returns self, while you do need to guarantee that all subclasses override a requirement that returns Self.
The requirement to guarantee that all subclasses provide this override is the reason you cannot declare conformance in the case of requirements returning Self. Since this isn�t necessary for self (will probably have a different name) the class does not need to be final in order to conform.
Ahh, this is different than what I have been talking about as it statically evaluates at the call site rather than the declaration site. Sorry, I think I missed your earlier post.
This would be no different from #file or #line in a default argument position, I think. If you use it in normal code:
it would evaluate as we’ve been discussing elsewhere here. I have had cases though, where using in a default parameter slot would be useulf (assuming it evaluates like #file and #line in those cases).
One question about this - how would it work if this method was called in a lexical con txt without an enclosing type declaration? Would that be an error or would it just require a parameter to be passed?
I would expect it to be an error if there were no enclosing type and the parameter wasn’t specified (but yeah, passing an explicit type should work).
If we call what I am talking about Type and we also want this behavior we should call it #Type as it would be the static type at the call site. But they are separate ideas and should be separate proposals.
Again, this would only be the case in a default argument position; it would work just like the other “#” symbols.
-tim
···
On May 10, 2016, at 3:53 PM, Matthew Johnson <matthew@anandabits.com> wrote:
If the use case is to support certain protocol requirements rather than
avoiding the recitation of long names, then it doesn't have to be short.
IMO, `Type` is problematic because there's nothing in the meaning of the
word to distinguish from `Self`, and in any case it's already used for the
metatype type. `StaticSelf` is unambiguous.
···
On Tue, May 10, 2016 at 5:32 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:
Sent from my iPad
On May 10, 2016, at 5:24 PM, Hooman Mehr <hooman@mac.com> wrote:
On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:
That said, I’m not sure I understand the concrete use-cases. When is this
concept important? When is “Self” not good enough?
The only case where there is new functionality is when this is used in a
protocol requirement. I gave an example earlier today.
This functionality is the key: Ability of an open (non-final) class to
conform to a protocol that lets it return an instance of the conforming
type (itself). Self does not work for that and we can’t change its behavior
(or can we?) So one solution seems to be Matt’s proposal. This
functionality is important for me and an example use case is class
clusters. For the client code it is sealed and acts just like a final
class, but internally it may return a subclass that is an implementation
detail. We should be able to do this.
Agree and this is why I am willing to write the proposal for this. There
was a discussion a few months ago about this problem and a few solutions
were kicked around. The biggest problem with this approach at the time was
lack of a good name, which I believe we now have in Type.
I'm going to let the discussion continue for a day or two and will write a
proposal if no significant counter arguments arise.
That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?
The only case where there is new functionality is when this is used in a protocol requirement. I gave an example earlier today.
This functionality is the key: Ability of an open (non-final) class to conform to a protocol that lets it return an instance of the conforming type (itself). Self does not work for that and we can’t change its behavior (or can we?) So one solution seems to be Matt’s proposal. This functionality is important for me and an example use case is class clusters. For the client code it is sealed and acts just like a final class, but internally it may return a subclass that is an implementation detail. We should be able to do this.
Help me understand this. Maybe an example will help. Why is it a problem to return the subclass instead of the base class?
The problem is that there is no way to guarantee that all subclasses of a non-final class provide the necessary override. See the NSURL example I posted earlier today.
···
Sent from my iPad
On May 10, 2016, at 5:46 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Tue, May 10, 2016 at 5:24 PM, Hooman Mehr via swift-evolution <swift-evolution@swift.org> wrote:
On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote: