[swift-evolution] Type-safe selectors

Michel Fortin michel.fortin at michelf.ca
Sun Dec 6 09:26:33 CST 2015

Le 5 déc. 2015 à 22:35, Kevin Ballard <kevin at sb.org> a écrit :

> Which is in the context of the fact that @convention(selector) MyObject
> -> Args -> Ret encodes the receiver type, but the problem is the
> selector is sent to AnyObject, so having the receiver type in there is
> basically false type-safety (it looks like it's strongly-typed but it's
> actually not as that type information will be thrown away before the
> selector is used). I'm not really sure why Michel claimed that your
> closure suggestion was a solution to this problem, because the only
> reasonable behavior one can use in such a category emitted on
> AnyObject/swift base class is to fatalError, which is no better than
> what happens if the selector simply isn't implemented.

Somehow in the thinking process I forgot that the category could have been put on MyObject instead of NSObject. I agree it's better to set the category on MyObject.

As for why a category at all? The risk is that another class implements "doSomething:" with a different argument type or return type than the "doSomething:" referring to, and that somehow an object of this other class becomes the target. In that case you want to halt the program to avoid the other "doSomething:" method from being called. That's why I suggested using a unique selector. And that idea came from Joe's suggestion of creating unique selectors from context-free closures.

>> There's plenty of useful space between "no type safety" and "perfect type safety", IMO.
> In principle I agree. My basic argument here is that
> @convention(selector) provides so little actual type safety that it's
> not worth the language complexity. And I also worry that providing
> functionality that appears to be strongly-typed but doesn't actually
> provide any typing guarantees in practice will end up as a safety hazard
> for unwary programmers.

This is a reasonable concern. My opinion is that for @convention(selector) to be worthwhile, it needs to be safe.. If it can't be made safe, then maybe the idea probably should be abandoned. I think we are on the same page here, except that I'm more optimistic about type-safety.

> It's also worth pointing out that my alternative suggestion of simply
> providing some syntax to explicitly get a Selector from a method could
> still use your closure-generating idea to work for non- at objc methods.
> Heck, we don't even really need syntax for this, we could just say that
> unbound method references can resolve to Selectors in addition to
> function types (just as the primary suggestion here allows method
> references to resolve to @convention(selector) functions in addition to
> @convention(swift) functions).

Most ideas floating in this thread are actually not mutually exclusive. I wouldn't qualify them as "alternatives" really since they can easily combine. We should look at the tradeoff of each and keep the good ones.

Michel Fortin
michel.fortin at michelf.ca

More information about the swift-evolution mailing list