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