> On Dec 11, 2016, at 2:30 AM, Tommaso Piazza via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
