In these case of module operator conflicts perhaps there could be a way we could import these operators ?
Likes a #importOperators(OtherModule) or some kind of build flag. *___________________________________* *James⎥Future Prime Minister* *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>* *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On Sun, Apr 3, 2016 at 12:26 PM, Ross O'Brien via swift-evolution < swift-evolution@swift.org> wrote: > There is a problem here of duplicated operators or custom precedence, and > how that gets passed between modules. > Assume there are three modules, A, B and C. B defines a custom operator > **. A and C each define a custom operator ++, and their meanings are > different (though, even if their meanings were the same, I'm not sure if > they could unify). > > Module D uses A and B as dependencies and sets a custom precedence on ++ > and **. Module E uses B and C and has a different precedence on ++ and **. > You're working on Module F which uses D and E. Which ++ and which > precedence does F get implicitly? > > I'm wondering whether we can treat operators the way we recently decided > to treat selectors: if there is an ambiguity, it should be possible not > just to specify which module they came from, but their fixity or argument > types. If module D decides that '++' should refer to 'traditional postfix > number incrementation', and F decides that it should be an infix 'conjoin > two numbers as a string and turn the result into a number (e.g. 5 ++ 4 -> > 54)' then a #selector-like operator signature would come in really handy. > > > On Sun, Apr 3, 2016 at 12:10 PM, Taras Zakharko via swift-evolution < > swift-evolution@swift.org> wrote: > >> I think this is a great suggestion! One potential problem I can see (if I >> understood this correctly) is that modules are allowed to set up their own >> precedence rules for operators defined elsewhere. I think this might lead >> to some difficult to debug errors if a developer of one module (who is used >> to certain conventions) then has to work with a different, independent >> module (where the conventions are different). This is one area where >> numerical precedence weights seem to be superior as they at least refer to >> a common subjective coordinate system. >> >> Maybe one should also have visibility for precedence, for instance having >> precedence module-internal by default? >> >> Best, >> >> — Taras >> >> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Swift 2.2 is out, and I restart discussion on syntax for custom >> operators. I insist that this time we should focus less on linguistic >> aspects. >> >> >> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md >> >> Introduction >> >> Replace syntax of operator definition: >> >> infix operator <> { precedence 100 associativity left } >> >> With a directive: >> >> #operator(<>, fixity: infix, associativity: left) >> >> Also replace numeric definition of precedence with separate comparative >> precedence definitions: >> >> #precedence(+, lessThan: *) >> #precedence(+, equalTo: -) >> >> Swift-evolution thread: link to the discussion thread for that proposal >> <https://lists.swift.org/pipermail/swift-evolution> >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#motivation> >> Motivation >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#problems-with-numeric-definition-of-precedence>Problems >> with numeric definition of precedence >> >> In the beginning, operators had nice precedence values: 90, 100, 110, >> 120, 130, 140, 150, 160. >> >> As time went, new and new operators were introduced. Precedence could not >> be simply changed, as this would be a breaking change. Ranges got >> precedence 135, as got precedence 132. ?? had precedence greater than <, >> but less thanas, so it had to be given precedence 131. >> >> Now it is not possible to insert any custom operator between < and ??. >> It is an inevitable consequence of current design: it will be impossible to >> insert an operator between two existing ones at some point. >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#problems-with-a-single-precedence-hierarchy>Problems >> with a single precedence hierarchy >> >> Currently, if an operator wants to define precedence by comparison to one >> operator, it must do so for all other operators. >> >> In many cases, this is not wished. Example: a & b < c is a common error >> pattern. a / b as Double is another one. C++ compilers sometimes emit >> warnings on these. Swift does not. >> >> The root of the problem is that precedence is defined between all >> operators. If & had precedence defined only by comparison to other >> bitwise operators and / – only to arithmetic operators, we would have to >> place parentheses in such places, not get subtle bugs, and not ever have to >> look at the huge operator precedence table. >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#problems-with-current-operator-definition-syntax>Problems >> with current operator definition syntax >> >> Some argue that current operator syntax is not consistent with other >> language constructs. Properties of operators have dictionary semantics and >> should be defined as such. It is a rather weak argument right now, but >> after reworking of precedence, the new syntax will be more to place. More >> reasons are given below. >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#conflicts-of-operator-definitions>Conflicts >> of operator definitions >> >> Consider two operator definitions in different modules. >> >> Module A: >> >> infix operator |> { precedence 137 associativity left } >> >> Module B: >> >> infix operator |> { precedence 138 associativity left } >> >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#proposed-solution>Proposed >> solution >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#change-syntax-for-operator-definition>Change >> syntax for operator definition >> >> #operator(<>, fixity: infix, associativity: left) >> #operator(!, fixity: postfix) >> >> First parameter of #operator directive is name of the operator. Then >> goes required parameter fixity that can be infix,prefix, or postfix. >> Then, for infix operators, goes optional associativity parameter that >> can be left or right. >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#comparative-precedence>Comparative >> precedence >> >> Remove precedence property from operator definitions. Instead, introduce >> #precedence directive: >> >> #precedence(+, lessThan: *) >> #precedence(*, equalTo: /) >> >> Omission of parentheses is allowed only when precedence between the two >> operators is defined. >> >> 1 + 2 * 3 // ok1 + 2 - 3 // error! >> #precedence(-, equalTo: +)1 + 2 - 3 // now ok >> >> Precedence equality can only be defined for operators with same >> associativity. >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#conflict-resolution>Conflict >> resolution >> >> Precedence rules can be added freely across modules. Ability to omit >> parentheses around more operators will not break any code in included >> modules. On the other hand, conflicting precedence rules result in an error: >> >> #precedence(*, lessThan: +) // error, previously defined `+` < `*` >> >> Operator definitions do nut cause conflicts, unless they are infix and >> one of them has associativity: left, but another one has associativity: >> right. >> >> #operator(!, fixity: prefix) // ok, duplicated definitions >> #operator(<>, fixity: infix) >> #operator(<>, fixity: infix, associativity: left) // ok, now left >> associative >> #operator(+, fixity: infix, associativity: right) // error: associativity >> conflict >> >> So, if two modules define a custom operator with somewhat similar >> semantics (at least associativity), they can be used together. Prefix and >> postfix operators can never have conflicts in definitions. If they define >> different precedence by comparison to same operators, then, most probably, >> they had completely different semantics, and the situation is similar to >> conflict of functions. >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#detailed-design>Detailed >> design >> >> operator keyword and local keywords associativity, precedence, left, >> right will be removed. >> >> Directives with following (informal) syntax will be added: >> >> #operator(OPERATOR_NAME, fixity: FIXITY) >> #operator(OPERATOR_NAME, fixity: infix, associativity: ASSOCIATIVITY) >> #precedence(OPERATOR_NAME, lessThan: OPERATOR_NAME) >> #precedence(OPERATOR_NAME, equalTo: OPERATOR_NAME) >> >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#impact-on-existing-code>Impact >> on existing code >> >> Standard library operator declarations will need to be rewritten. Some of >> the existing precedence rules will need to be rewritten using #precedence >> directive. >> >> More importantly, it needs to be discussed what operator precedence rules >> do *not* need to be retained. >> >> User defined operators will need to be rewritten as well. But precedence >> will have to be defined by the user. Meanwhile, we can automatically insert >> parentheses to user code where needed. >> >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#alternatives-considered>Alternatives >> considered >> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#leave-current-operator-syntax-but-change-precedence>Leave >> current operator syntax (but change precedence) >> >> #precedence does not make sense to be defined inside of operator >> definition, as it describes relationship of two operators. If so, then we >> are left with the following declaration syntax: >> >> prefix operator ! { }infix operator |> { }infix operator <> { associativity >> left } >> >> If body of operator can only contain associativity (in some cases), then >> the existence of body itself makes no sense. >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution