[swift-evolution] Some concerns on custom operators
antonyzhilin at gmail.com
Wed Nov 9 14:16:27 CST 2016
2016-11-09 22:20 GMT+03:00 John McCall <rjmccall at apple.com>:
> > On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution <
> swift-evolution at swift.org> wrote:
> > • Upon implementation of SE-0077 in Swift 3, some libraries
> started to drop operators entirely: link #1, link #2.
> > • Declarations of the same custom operator with different
> precedence groups create a conflict.
> > • The conflict can be resolved manually, but the
> resolution has to be made in every file that uses the operator, which
> defeats the reason for using operators in the first place.
> > • This is a part of a larger problem of conflict
> resolution, for which we don’t currently have a systematic approach.
> It makes sense to me to provide a more module-wide conflict resolution
> mechanism. Maybe we can have some sort of "internal export" mechanism
> where a file can introduce imports into other files within a project.
It would also be generally useful for modules that are made use of
throughout the project, like logging or those generic operators and
collections libraries. I can create a proposal for that.
> • Many libraries dealing with custom operators choose to
> import Runes, which is basically a stockpile of operator declarations. But
> it conflicts with Result, Swiftx and Operadics.
> Won't this just shake itself out pretty soon, assuming these projects have
> any interest in interoperating?
Maybe. Anyway, "internal import" can make such conflicts not that much of a
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution