16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
98 lines
2.8 KiB
Plaintext
98 lines
2.8 KiB
Plaintext
== Why is this an issue?
|
|
|
|
Making an operator a convenience wrapper around an existing function or method provides additional flexibility to users in how the functionality is called and in what options are passed in.
|
|
|
|
|
|
This rule raises an issue when the function that defines the operation of a operator consists of something other than a single function call.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,swift]
|
|
----
|
|
infix operator >< { associativity right precedence 90 }
|
|
func >< (left: Double, right: Double) -> Double { // Noncompliant
|
|
let leftD = (left % 1) * 100
|
|
let rightD = (right % 1) * 100
|
|
let leftW = (left - leftD) / 100
|
|
let rightW = (right - rightD) / 100
|
|
return (leftD + leftW) * (rightD + rightW)
|
|
}
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,swift]
|
|
----
|
|
infix operator >< { associativity right precedence 90 }
|
|
func >< (left: Double, right: Double) -> Double {
|
|
return fubar(left, right)
|
|
}
|
|
|
|
func fubar(left: Double, right: Double) -> Double {
|
|
let leftD = (left % 1) * 100
|
|
let rightD = (right % 1) * 100
|
|
let leftW = (left - leftD) / 100
|
|
let rightW = (right - rightD) / 100
|
|
return (leftD + leftW) * (rightD + rightW)
|
|
}
|
|
----
|
|
|
|
|
|
=== Exceptions
|
|
|
|
Operators that end with ``++=++`` are expected to update their left-hand operands, and are therefore ignored.
|
|
|
|
[source,swift]
|
|
----
|
|
func **= (inout p1:Int, p2:Int) {
|
|
p1 = p1 ** p2
|
|
}
|
|
----
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Move the body of this operator function into another function and call the function from here.
|
|
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== on 19 Jun 2015, 13:59:23 Elena Vilchik wrote:
|
|
\[~ann.campbell.2] What about less strict raising issue?
|
|
|
|
"This rule raises an issue when the function that defines the operation of a custom operator consists of something other than a single *return statement*."
|
|
|
|
(we don't care about return value expression)
|
|
|
|
=== on 19 Jun 2015, 15:42:20 Ann Campbell wrote:
|
|
That's up to you [~elena.vilchik], but if the point of the rule is to off-load the logic into another function for flexibility, then people can get around the rule if they can cram all the functionality into a single line without actually fulfilling the purpose. E.G.
|
|
|
|
----
|
|
return (( (left % 1) * 100) + ((left - ( (left % 1) * 100)) / 100)) * (((right % 1) * 100) + ((right - ((right % 1) * 100)) / 100))
|
|
----
|
|
|
|
|
|
|
|
=== on 19 Jun 2015, 15:46:16 Elena Vilchik wrote:
|
|
\[~ann.campbell.2] do you have nothing else to do?))
|
|
|
|
Ok, let's keep it as it is :)
|
|
|
|
=== on 24 Jun 2015, 09:26:05 Elena Vilchik wrote:
|
|
\[~ann.campbell.2] I've added exception and removed all mentioning of "custom" as this rule is about all operator functions. Could you verify?
|
|
|
|
=== on 24 Jun 2015, 13:49:29 Ann Campbell wrote:
|
|
I've made some minor edits [~elena.vilchik]. Double-check me, please.
|
|
|
|
endif::env-github,rspecator-view[]
|