Re: [swift-evolution] Calling a Specific Implementation

[John McCall via swift-evolution]

> On Aug 19, 2016, at 1:10 PM, John McCall  wrote:
>> On Aug 19, 2016, at 12:56 PM, Jonathan Hull > > wrote:
>> 
>> For my own education, how is does it break the encapsulation in a way which 
>> subclassing does not?  I may not have mentioned it, but in my mind, this 
>> construct would be limited by the compiler to being called from within a 
>> conforming type (in the same way super is).  Given that, 
> 
> You did not, in fact, mention that. :)  Like "super", you would still want to 
> restrict this to "self", or at the very least to only objects of your own 
> class type, so that you can't just make a subclass and then apply it to an 
> arbitrary object.
> 
> In that case, it's basically just super dispatch, except that you can go to 
> an arbitrary protocol-extension implementation.  (Unless you really want to 
> be able to skip your superclass's implementation, which is 
> encapsulation-breaking again.)

Although I suppose we could allow this kind of explicit encapsulation-break 
when you're in the right access-control scope, assuming it's really useful.

John.

> 
> John. 
> 
>> it seems to me that the considerations by both the ancestor class and the 
>> subclass would be exactly the same as in a super-subclass relationship.  I 
>> agree that it wouldn’t be a frequent use case, but I have definitely had 
>> times where it would have greatly simplified my class structure if allowed.  
>> I don’t see any reason to limit it (beyond the needs of the type), but I 
>> could easily be missing something fairly obvious...
>> 
>> Thanks,
>> Jon
>> 
>>> On Aug 17, 2016, at 6:57 PM, John McCall >> > wrote:
>>> 
 On Aug 17, 2016, at 5:46 PM, Jonathan Hull via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 I believe this affects the ABI (especially the second part), but if not, 
 let me know and we can talk about it in phase 2...
 
 There are times where you would like to call a specific implementation of 
 a method.  One of the most common is calling super from a subclass, but 
 you may want to do similar things when overriding a default implementation 
 of a protocol.  I also have definitely had times where I wanted to call 
 the implementation of an ancestor other than super.  It also solves some 
 of the issues that came up during the non-subclassable by default 
 discussion, because it allows you to statically dispatch to a known 
 implementation in cases where you need that assurance, but don’t want to 
 mark a method final.  (essentially it gives you the benefits of final for 
 a single call)
 
 Here are a couple of potential ideas on how to represent this (P 
 represents a protocol or class ancestor type):
 
varName.P::methodName
 
varName.methodName using P
 
 
 This is mainly to start a discussion, so feel free to counter-propose a 
 better syntax, etc…
 
 It seems fairly straightforward to me. The only objection that I remember 
 coming up when this was discussed before was that the compiler had to keep 
 some information around between modules that it wasn’t keeping around at 
 the time (which is what makes me think it affects the ABI). 
 
 One complication which could come up is what happens when P is a variable 
 holding a type instead of a constant type.  There are a few options:
 
 1) Don’t allow such shenanigans (compiler error)
 
 2) Dynamically dispatch based on a runtime check (trap at runtime if P is 
 not an ancestor/conformed-to protocol)
 
 3) Same as 2, except that the protocol conformance uses duck-typing
 
 4) Same as 2/3, except the command is not executed instead of trapping
 
 Of those options, 1 is the simplest, but 3 is my favorite, as it is the 
 most powerful (but also has the largest impact on the ABI). 4 could 
 co-exist with 2/3 by adding a ‘?’ variant of the syntax (e.g. 
 varName.P?::methodName)
 
 Thoughts?
>>> 
>>> I think being able to name and call a specific protocol-extension method 
>>> would be an interesting enhancement.
>>> 
>>> Being able to bypass another class's overrides and jump to a specific 
>>> superclass implementation on an arbitrary method call is badly 
>>> encapsulation-breaking, and I can't think of any OO language with 
>>> first-class support for it besides C++.  In every other language I know of, 
>>> super dispatch is always restricted to the self object and only bypasses 
>>> the overrides of the current class and its subclasses.  Of course there are 
>>> runtime tricks you can play to get this in, say, ObjC, but I'm not aware of 
>>> them being frequently used.  I would really to see concrete evidence of 
>>> this being useful and necessary before considering it any further.
>>> 
>>> John.
>> 
> 

___
swift-evolution mailing lis

Re: [swift-evolution] Calling a Specific Implementation

[John McCall via swift-evolution]

> On Aug 19, 2016, at 12:56 PM, Jonathan Hull  wrote:
> 
> For my own education, how is does it break the encapsulation in a way which 
> subclassing does not?  I may not have mentioned it, but in my mind, this 
> construct would be limited by the compiler to being called from within a 
> conforming type (in the same way super is).  Given that, 

You did not, in fact, mention that. :)  Like "super", you would still want to 
restrict this to "self", or at the very least to only objects of your own class 
type, so that you can't just make a subclass and then apply it to an arbitrary 
object.

In that case, it's basically just super dispatch, except that you can go to an 
arbitrary protocol-extension implementation.  (Unless you really want to be 
able to skip your superclass's implementation, which is encapsulation-breaking 
again.)

John. 

> it seems to me that the considerations by both the ancestor class and the 
> subclass would be exactly the same as in a super-subclass relationship.  I 
> agree that it wouldn’t be a frequent use case, but I have definitely had 
> times where it would have greatly simplified my class structure if allowed.  
> I don’t see any reason to limit it (beyond the needs of the type), but I 
> could easily be missing something fairly obvious...
> 
> Thanks,
> Jon
> 
>> On Aug 17, 2016, at 6:57 PM, John McCall > > wrote:
>> 
>>> On Aug 17, 2016, at 5:46 PM, Jonathan Hull via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I believe this affects the ABI (especially the second part), but if not, 
>>> let me know and we can talk about it in phase 2...
>>> 
>>> There are times where you would like to call a specific implementation of a 
>>> method.  One of the most common is calling super from a subclass, but you 
>>> may want to do similar things when overriding a default implementation of a 
>>> protocol.  I also have definitely had times where I wanted to call the 
>>> implementation of an ancestor other than super.  It also solves some of the 
>>> issues that came up during the non-subclassable by default discussion, 
>>> because it allows you to statically dispatch to a known implementation in 
>>> cases where you need that assurance, but don’t want to mark a method final. 
>>>  (essentially it gives you the benefits of final for a single call)
>>> 
>>> Here are a couple of potential ideas on how to represent this (P represents 
>>> a protocol or class ancestor type):
>>> 
>>> varName.P::methodName
>>> 
>>> varName.methodName using P
>>> 
>>> 
>>> This is mainly to start a discussion, so feel free to counter-propose a 
>>> better syntax, etc…
>>> 
>>> It seems fairly straightforward to me. The only objection that I remember 
>>> coming up when this was discussed before was that the compiler had to keep 
>>> some information around between modules that it wasn’t keeping around at 
>>> the time (which is what makes me think it affects the ABI). 
>>> 
>>> One complication which could come up is what happens when P is a variable 
>>> holding a type instead of a constant type.  There are a few options:
>>> 
>>> 1) Don’t allow such shenanigans (compiler error)
>>> 
>>> 2) Dynamically dispatch based on a runtime check (trap at runtime if P is 
>>> not an ancestor/conformed-to protocol)
>>> 
>>> 3) Same as 2, except that the protocol conformance uses duck-typing
>>> 
>>> 4) Same as 2/3, except the command is not executed instead of trapping
>>> 
>>> Of those options, 1 is the simplest, but 3 is my favorite, as it is the 
>>> most powerful (but also has the largest impact on the ABI). 4 could 
>>> co-exist with 2/3 by adding a ‘?’ variant of the syntax (e.g. 
>>> varName.P?::methodName)
>>> 
>>> Thoughts?
>> 
>> I think being able to name and call a specific protocol-extension method 
>> would be an interesting enhancement.
>> 
>> Being able to bypass another class's overrides and jump to a specific 
>> superclass implementation on an arbitrary method call is badly 
>> encapsulation-breaking, and I can't think of any OO language with 
>> first-class support for it besides C++.  In every other language I know of, 
>> super dispatch is always restricted to the self object and only bypasses the 
>> overrides of the current class and its subclasses.  Of course there are 
>> runtime tricks you can play to get this in, say, ObjC, but I'm not aware of 
>> them being frequently used.  I would really to see concrete evidence of this 
>> being useful and necessary before considering it any further.
>> 
>> John.
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[Charlie Monroe via swift-evolution]

A agree with John. Imagine 

class A {
func foo() -> Int {
return bar()
}
func bar() -> Int {
return 0
}
}

class B {
override foo() -> Int {
return bar() + 1
}   
overr func bar() -> Int {
return 32
}
}

What would A(foo) return? Some would say that 0, some that 32...


> On Aug 19, 2016, at 5:14 PM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> What if two modules declare the same extension method?
> 
> Félix
> 
>> Le 19 août 2016 à 03:06:23, Brent Royal-Gordon via swift-evolution 
>>  a écrit :
>> 
>>> On Aug 17, 2016, at 6:57 PM, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> Being able to bypass another class's overrides and jump to a specific 
>>> superclass implementation on an arbitrary method call is badly 
>>> encapsulation-breaking, and I can't think of any OO language with 
>>> first-class support for it besides C++.
>> 
>> Perl 5 does, although of course its object system is a little 
>> bit...different.
>> 
>> What these languages have in common is multiple inheritance. Calling a 
>> specific superclass's implementation is necessary when you have more than 
>> one superclass. Swift doesn't have that problem with superclasses, but it 
>> *does* have it with protocol extension members.
>> 
>> My suggestion would be to allow you to call a particular protocol 
>> extension's implementation with:
>> 
>>  super(ProtocolName).method()
>> 
>> `super(Foo)` would always use the appropriate member on `Foo`, which must be 
>> a protocol (not a class name), and must be conformed to by this type (not by 
>> a superclass).  Unqualified `super` would only be valid in classes and would 
>> only permit calls to members of the superclass (including protocols it 
>> conforms to). That would permit access to default implementations without 
>> permitting encapsulation-breaking shenanigans, while leaving plain `super`'s 
>> meaning unambiguous.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[Jonathan Hull via swift-evolution]

For my own education, how is does it break the encapsulation in a way which 
subclassing does not?  I may not have mentioned it, but in my mind, this 
construct would be limited by the compiler to being called from within a 
conforming type (in the same way super is).  Given that, it seems to me that 
the considerations by both the ancestor class and the subclass would be exactly 
the same as in a super-subclass relationship.  I agree that it wouldn’t be a 
frequent use case, but I have definitely had times where it would have greatly 
simplified my class structure if allowed.  I don’t see any reason to limit it 
(beyond the needs of the type), but I could easily be missing something fairly 
obvious...

Thanks,
Jon

> On Aug 17, 2016, at 6:57 PM, John McCall  wrote:
> 
>> On Aug 17, 2016, at 5:46 PM, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> I believe this affects the ABI (especially the second part), but if not, let 
>> me know and we can talk about it in phase 2...
>> 
>> There are times where you would like to call a specific implementation of a 
>> method.  One of the most common is calling super from a subclass, but you 
>> may want to do similar things when overriding a default implementation of a 
>> protocol.  I also have definitely had times where I wanted to call the 
>> implementation of an ancestor other than super.  It also solves some of the 
>> issues that came up during the non-subclassable by default discussion, 
>> because it allows you to statically dispatch to a known implementation in 
>> cases where you need that assurance, but don’t want to mark a method final.  
>> (essentially it gives you the benefits of final for a single call)
>> 
>> Here are a couple of potential ideas on how to represent this (P represents 
>> a protocol or class ancestor type):
>> 
>>  varName.P::methodName
>> 
>>  varName.methodName using P
>> 
>> 
>> This is mainly to start a discussion, so feel free to counter-propose a 
>> better syntax, etc…
>> 
>> It seems fairly straightforward to me. The only objection that I remember 
>> coming up when this was discussed before was that the compiler had to keep 
>> some information around between modules that it wasn’t keeping around at the 
>> time (which is what makes me think it affects the ABI). 
>> 
>> One complication which could come up is what happens when P is a variable 
>> holding a type instead of a constant type.  There are a few options:
>> 
>> 1) Don’t allow such shenanigans (compiler error)
>> 
>> 2) Dynamically dispatch based on a runtime check (trap at runtime if P is 
>> not an ancestor/conformed-to protocol)
>> 
>> 3) Same as 2, except that the protocol conformance uses duck-typing
>> 
>> 4) Same as 2/3, except the command is not executed instead of trapping
>> 
>> Of those options, 1 is the simplest, but 3 is my favorite, as it is the most 
>> powerful (but also has the largest impact on the ABI). 4 could co-exist with 
>> 2/3 by adding a ‘?’ variant of the syntax (e.g. varName.P?::methodName)
>> 
>> Thoughts?
> 
> I think being able to name and call a specific protocol-extension method 
> would be an interesting enhancement.
> 
> Being able to bypass another class's overrides and jump to a specific 
> superclass implementation on an arbitrary method call is badly 
> encapsulation-breaking, and I can't think of any OO language with first-class 
> support for it besides C++.  In every other language I know of, super 
> dispatch is always restricted to the self object and only bypasses the 
> overrides of the current class and its subclasses.  Of course there are 
> runtime tricks you can play to get this in, say, ObjC, but I'm not aware of 
> them being frequently used.  I would really to see concrete evidence of this 
> being useful and necessary before considering it any further.
> 
> John.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[Félix Cloutier via swift-evolution]

What if two modules declare the same extension method?

Félix

> Le 19 août 2016 à 03:06:23, Brent Royal-Gordon via swift-evolution 
>  a écrit :
> 
>> On Aug 17, 2016, at 6:57 PM, John McCall via swift-evolution 
>>  wrote:
>> 
>> Being able to bypass another class's overrides and jump to a specific 
>> superclass implementation on an arbitrary method call is badly 
>> encapsulation-breaking, and I can't think of any OO language with 
>> first-class support for it besides C++.
> 
> Perl 5 does, although of course its object system is a little bit...different.
> 
> What these languages have in common is multiple inheritance. Calling a 
> specific superclass's implementation is necessary when you have more than one 
> superclass. Swift doesn't have that problem with superclasses, but it *does* 
> have it with protocol extension members.
> 
> My suggestion would be to allow you to call a particular protocol extension's 
> implementation with:
> 
>   super(ProtocolName).method()
> 
> `super(Foo)` would always use the appropriate member on `Foo`, which must be 
> a protocol (not a class name), and must be conformed to by this type (not by 
> a superclass).  Unqualified `super` would only be valid in classes and would 
> only permit calls to members of the superclass (including protocols it 
> conforms to). That would permit access to default implementations without 
> permitting encapsulation-breaking shenanigans, while leaving plain `super`'s 
> meaning unambiguous.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[Brent Royal-Gordon via swift-evolution]

> On Aug 17, 2016, at 6:57 PM, John McCall via swift-evolution 
>  wrote:
> 
> Being able to bypass another class's overrides and jump to a specific 
> superclass implementation on an arbitrary method call is badly 
> encapsulation-breaking, and I can't think of any OO language with first-class 
> support for it besides C++.

Perl 5 does, although of course its object system is a little bit...different.

What these languages have in common is multiple inheritance. Calling a specific 
superclass's implementation is necessary when you have more than one 
superclass. Swift doesn't have that problem with superclasses, but it *does* 
have it with protocol extension members.

My suggestion would be to allow you to call a particular protocol extension's 
implementation with:

super(ProtocolName).method()

`super(Foo)` would always use the appropriate member on `Foo`, which must be a 
protocol (not a class name), and must be conformed to by this type (not by a 
superclass).  Unqualified `super` would only be valid in classes and would only 
permit calls to members of the superclass (including protocols it conforms to). 
That would permit access to default implementations without permitting 
encapsulation-breaking shenanigans, while leaving plain `super`'s meaning 
unambiguous.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[Slava Pestov via swift-evolution]

> On Aug 18, 2016, at 8:21 PM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
>> On 18 Aug 2016, at 16:32, John McCall  wrote:
>> 
>> Unapplied method references still dispatch down.  It's a pretty simple 
>> experiment to run for yourself.
> 
> When I tried calling a specific superclass implementation, there was a stack 
> overflow due to the infinite recursion.

This is because calling Once.value() with an instance of Twice still dispatches 
to Twice::value().

> 
>   class Once {
>   func value() -> Int {
>   return 1
>   }
>   }
> 
>   class Twice: Once {
>   override func value() -> Int {
>   return 2
>   }
>   }
> 
>   class Thrice: Twice {
>   override func value() -> Int {
>   return 3
> 
>   // EXC_BAD_ACCESS:
>   // return Once.value(self)()
>   }
>   }
> 
>   let once = Once()
>   once.value()//-> 1
>   Once.value(once)()  //-> 1
> 
>   let twice = Twice()
>   twice.value()   //-> 2
>   Once.value(twice)() //-> 2
>   Twice.value(twice)()//-> 2
> 
>   let thrice = Thrice()
>   thrice.value()  //-> 3
>   Once.value(thrice)()//-> 3
>   Twice.value(thrice)()   //-> 3
>   Thrice.value(thrice)()  //-> 3
> 
> -- Ben
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[Ben Rimmington via swift-evolution]

> On 18 Aug 2016, at 16:32, John McCall  wrote:
> 
> Unapplied method references still dispatch down.  It's a pretty simple 
> experiment to run for yourself.

When I tried calling a specific superclass implementation, there was a stack 
overflow due to the infinite recursion.

class Once {
func value() -> Int {
return 1
}
}

class Twice: Once {
override func value() -> Int {
return 2
}
}

class Thrice: Twice {
override func value() -> Int {
return 3

// EXC_BAD_ACCESS:
// return Once.value(self)()
}
}

let once = Once()
once.value()//-> 1
Once.value(once)()  //-> 1

let twice = Twice()
twice.value()   //-> 2
Once.value(twice)() //-> 2
Twice.value(twice)()//-> 2

let thrice = Thrice()
thrice.value()  //-> 3
Once.value(thrice)()//-> 3
Twice.value(thrice)()   //-> 3
Thrice.value(thrice)()  //-> 3

-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[John McCall via swift-evolution]

> On Aug 17, 2016, at 7:24 PM, Ben Rimmington  wrote:
>> On 18 Aug 2016, at 02:57, John McCall wrote:
>> 
>> Being able to bypass another class's overrides and jump to a specific 
>> superclass implementation on an arbitrary method call is badly 
>> encapsulation-breaking, and I can't think of any OO language with 
>> first-class support for it besides C++.  In every other language I know of, 
>> super dispatch is always restricted to the self object and only bypasses the 
>> overrides of the current class and its subclasses. Of course there are 
>> runtime tricks you can play to get this in, say, ObjC, but I'm not aware of 
>> them being frequently used.  I would really to see concrete evidence of this 
>> being useful and necessary before considering it any further.
> 
> Doesn't this already exist as "unapplied method references" in Swift?

Unapplied method references still dispatch down.  It's a pretty simple 
experiment to run for yourself.

John.

> 
> 
> 
> SE-0042 isn't implemented yet, so maybe the curried version should be 
> deprecated?
> 
> -- Ben
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[Ben Rimmington via swift-evolution]

> On 18 Aug 2016, at 02:57, John McCall wrote:
> 
> Being able to bypass another class's overrides and jump to a specific 
> superclass implementation on an arbitrary method call is badly 
> encapsulation-breaking, and I can't think of any OO language with first-class 
> support for it besides C++.  In every other language I know of, super 
> dispatch is always restricted to the self object and only bypasses the 
> overrides of the current class and its subclasses. Of course there are 
> runtime tricks you can play to get this in, say, ObjC, but I'm not aware of 
> them being frequently used.  I would really to see concrete evidence of this 
> being useful and necessary before considering it any further.

Doesn't this already exist as "unapplied method references" in Swift?



SE-0042 isn't implemented yet, so maybe the curried version should be 
deprecated?

-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Calling a Specific Implementation

[John McCall via swift-evolution]

> On Aug 17, 2016, at 5:46 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I believe this affects the ABI (especially the second part), but if not, let 
> me know and we can talk about it in phase 2...
> 
> There are times where you would like to call a specific implementation of a 
> method.  One of the most common is calling super from a subclass, but you may 
> want to do similar things when overriding a default implementation of a 
> protocol.  I also have definitely had times where I wanted to call the 
> implementation of an ancestor other than super.  It also solves some of the 
> issues that came up during the non-subclassable by default discussion, 
> because it allows you to statically dispatch to a known implementation in 
> cases where you need that assurance, but don’t want to mark a method final.  
> (essentially it gives you the benefits of final for a single call)
> 
> Here are a couple of potential ideas on how to represent this (P represents a 
> protocol or class ancestor type):
> 
>   varName.P::methodName
> 
>   varName.methodName using P
> 
> 
> This is mainly to start a discussion, so feel free to counter-propose a 
> better syntax, etc…
> 
> It seems fairly straightforward to me. The only objection that I remember 
> coming up when this was discussed before was that the compiler had to keep 
> some information around between modules that it wasn’t keeping around at the 
> time (which is what makes me think it affects the ABI). 
> 
> One complication which could come up is what happens when P is a variable 
> holding a type instead of a constant type.  There are a few options:
> 
> 1) Don’t allow such shenanigans (compiler error)
> 
> 2) Dynamically dispatch based on a runtime check (trap at runtime if P is not 
> an ancestor/conformed-to protocol)
> 
> 3) Same as 2, except that the protocol conformance uses duck-typing
> 
> 4) Same as 2/3, except the command is not executed instead of trapping
> 
> Of those options, 1 is the simplest, but 3 is my favorite, as it is the most 
> powerful (but also has the largest impact on the ABI). 4 could co-exist with 
> 2/3 by adding a ‘?’ variant of the syntax (e.g. varName.P?::methodName)
> 
> Thoughts?

I think being able to name and call a specific protocol-extension method would 
be an interesting enhancement.

Being able to bypass another class's overrides and jump to a specific 
superclass implementation on an arbitrary method call is badly 
encapsulation-breaking, and I can't think of any OO language with first-class 
support for it besides C++.  In every other language I know of, super dispatch 
is always restricted to the self object and only bypasses the overrides of the 
current class and its subclasses.  Of course there are runtime tricks you can 
play to get this in, say, ObjC, but I'm not aware of them being frequently 
used.  I would really to see concrete evidence of this being useful and 
necessary before considering it any further.

John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Calling a Specific Implementation

[Jonathan Hull via swift-evolution]

I believe this affects the ABI (especially the second part), but if not, let me 
know and we can talk about it in phase 2...

There are times where you would like to call a specific implementation of a 
method.  One of the most common is calling super from a subclass, but you may 
want to do similar things when overriding a default implementation of a 
protocol.  I also have definitely had times where I wanted to call the 
implementation of an ancestor other than super.  It also solves some of the 
issues that came up during the non-subclassable by default discussion, because 
it allows you to statically dispatch to a known implementation in cases where 
you need that assurance, but don’t want to mark a method final.  (essentially 
it gives you the benefits of final for a single call)

Here are a couple of potential ideas on how to represent this (P represents a 
protocol or class ancestor type):

varName.P::methodName

varName.methodName using P


This is mainly to start a discussion, so feel free to counter-propose a better 
syntax, etc…

It seems fairly straightforward to me. The only objection that I remember 
coming up when this was discussed before was that the compiler had to keep some 
information around between modules that it wasn’t keeping around at the time 
(which is what makes me think it affects the ABI). 

One complication which could come up is what happens when P is a variable 
holding a type instead of a constant type.  There are a few options:

1) Don’t allow such shenanigans (compiler error)

2) Dynamically dispatch based on a runtime check (trap at runtime if P is not 
an ancestor/conformed-to protocol)

3) Same as 2, except that the protocol conformance uses duck-typing

4) Same as 2/3, except the command is not executed instead of trapping

Of those options, 1 is the simplest, but 3 is my favorite, as it is the most 
powerful (but also has the largest impact on the ABI). 4 could co-exist with 
2/3 by adding a ‘?’ variant of the syntax (e.g. varName.P?::methodName)

Thoughts?

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution