[swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Douglas Gregor]

> On Dec 11, 2016, at 2:30 AM, Tommaso Piazza via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Derrick,
> 
> I did not think of this as a bug but rather as an intentional limitation that to me seems a little odd.
> 
> Yes, overloads 2,3 have at least ONE operand of type NonEmptyArray so when declared as static function on NonEmptyArray they work fine. However Overload 1 just mentions NonEmptyArray in the return type. I propose that it should also be allowed as a static function on NonEmptyArray.

This was intentional:

	https://github.com/apple/swift/commit/a15c485193c4dcb61c330be8c2d869758fff2c45

We believe that this restriction will help us provide more fine-grained dependency tracking in the compiler, which is important for minimizing the work to be performed in incremental builds. The general idea is that one can only find a particular operator when one has an argument of the type in which the operator is defined (or one of its subclasses or conforming types). I believe that we lose this fine-grained dependency if we allow the enclosing type to be mentioned (only) in the result type. So unless I’m wrong about one of those two things—either we don’t actually get the fine-grained dependency I’m expecting or we can still get it even if the enclosing type is only mentioned in the result type—I’m strongly against lifting this restriction. Incremental build times and fine-grained dependencies are extremely important for Swift compile times, and the language already has a way out by defining a global operator.

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161213/6c5e3185/attachment.html>