[swift-evolution] Some concerns on custom operators

[Anton Zhilin]

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
problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161109/cd684768/attachment.html>