<= Is Not a Prefix Unary Operator

is not a prefix unary operator

Your code should be

} else if three >= 13 && three <= 19 {
    total = ("\(one) \(two) a teenager")
} else if three > 19 && three <= 29 {
    total = ("\(one) \(two) a young man")
} else if three >= 30 && three <= 49 {
    total = ("\(one) \(two) a middle aged man")
} else if three >= 50 && three <= 64 {
    total = ("\(one) \(two) an experienced man")
} else if three >= 65 {
    total = ("\(one) \(two) a senior man")
}

The reason for that is that as the error '<=' is not a prefix unary operator says <= is not a unary operator. Which is a operator which only needs one argument. <= however needs two operands, one before and one after - therefore it is a binary infix operator.

The better way would probably be using a switch statement and ranges instead as @MartinR correctly suggested. They follow the following pattern:

switch k {
    case Int.min...12:
        print("hi")
    case 13...45:
        print("bye")
    default:
        print("nah")
}

Alternatively (again as Martin suggested) simplify your ifs. Because the first if already captures all values between Int.Min and 11 your else-block does not need to check that the value is greater than 12 because if it wasn't the first would have already been true and the else would not even have been reached.

One final note:

What happens at age 12?

' is not a prefix unary operator

Leave out the ==:

 if messages.count > 75 {
     navigationItem.rightBarButtonItem?.isEnabled = true
 } else if messages.count < 75 {
     navigationItem.rightBarButtonItem?.isEnabled = false
 }

There's more than just ==, > and <:

• A == B means A is equal to B
• A != B means A is not equal to B
• A > B means A is greater than B
• A < B means A is less than B
• A >= B means A is greater than or equal to B
• A <= B means A is less than or equal to B

Check out the language docs here.

Swift: '==' is not a prefix unary operator

Try to add space after '=='.

Instead of :

if(result =="") {

try:

if(result == "") {

Lesser than or greater than in Swift switch statement

Here's one approach. Assuming someVar is an Int or other Comparable, you can optionally assign the operand to a new variable. This lets you scope it however you want using the where keyword:

var someVar = 3

switch someVar {
case let x where x < 0:
    print("x is \(x)")
case let x where x == 0:
    print("x is \(x)")
case let x where x > 0:
    print("x is \(x)")
default:
    print("this is impossible")
}

This can be simplified a bit:

switch someVar {
case _ where someVar < 0:
    print("someVar is \(someVar)")
case 0:
    print("someVar is 0")
case _ where someVar > 0:
    print("someVar is \(someVar)")
default:
    print("this is impossible")
}

You can also avoid the where keyword entirely with range matching:

switch someVar {
case Int.min..<0:
    print("someVar is \(someVar)")
case 0:
    print("someVar is 0")
default:
    print("someVar is \(someVar)")
}

Create unary operator in R

The R parser doesn't support custom unary operators.

A copy of the list of supported operators from the R language definition:

-   Minus, can be unary or binary
+   Plus, can be unary or binary
!   Unary not
~   Tilde, used for model formulae, can be either unary or binary
?   Help
:   Sequence, binary (in model formulae: interaction)
*   Multiplication, binary
/   Division, binary
^   Exponentiation, binary
%x% Special binary operators, x can be replaced by any valid name
%%  Modulus, binary
%/% Integer divide, binary
%*% Matrix product, binary
%o% Outer product, binary
%x% Kronecker product, binary
%in%    Matching operator, binary (in model formulae: nesting)
<   Less than, binary
>   Greater than, binary
==  Equal to, binary
>=  Greater than or equal to, binary
<=  Less than or equal to, binary
&   And, binary, vectorized
&&  And, binary, not vectorized
|   Or, binary, vectorized
||  Or, binary, not vectorized
<-  Left assignment, binary
->  Right assignment, binary
$   List subset, binary

(The parser supports also the binary operator := which is not documented here, because it is not used by base R.)

Note that the only custom operators ("%x% Special binary operators, x can be replaced by any valid name") are binary.

So, your only option is overloading an existing unary operator respectively writing a method for it.

The ++ and -- operators have been deprecated Xcode 7.3

A full explanation here from Chris Lattner, Swift's creator. I'll summarize the points:

1. It's another function you have to learn while learning Swift
2. Not much shorter than x += 1
3. Swift is not C. Shouldn't carry them over just to please C programmers
4. Its main use is in C-style for loop: for i = 0; i < n; i++ { ... }, which Swift has better alternatives, like for i in 0..<n { ... } (C-style for loop is going out as well)
5. Can be tricky to read and maintain, for eg, what's the value of x - ++x or foo(++x, x++)?
6. Chris Lattner doesn't like it.

---

For those interested (and to avoid link rot), Lattner's reasons in his own words are:

1. These operators increase the burden to learn Swift as a first programming language - or any other case where you don't already know these operators from a different language.

2. Their expressive advantage is minimal - x++ is not much shorter than x += 1.

3. Swift already deviates from C in that the =, += and other assignment-like operations returns Void (for a number of reasons). These operators are inconsistent with that model.

4. Swift has powerful features that eliminate many of the common reasons you'd use ++i in a C-style for loop in other languages, so these are relatively infrequently used in well-written Swift code. These features include the for-in loop, ranges, enumerate, map, etc.

5. Code that actually uses the result value of these operators is often confusing and subtle to a reader/maintainer of code. They encourage "overly tricky" code which may be cute, but difficult to understand.

6. While Swift has well defined order of evaluation, any code that depended on it (like foo(++a, a++)) would be undesirable even if it was well-defined.

7. These operators are applicable to relatively few types: integer and floating point scalars, and iterator-like concepts. They do not apply to complex numbers, matrices, etc.

Finally, these fail the metric of "if we didn't already have these, would we add them to Swift 3?"

Why are there no ++ and --​ operators in Python?

It's not because it doesn't make sense; it makes perfect sense to define "x++" as "x += 1, evaluating to the previous binding of x".

If you want to know the original reason, you'll have to either wade through old Python mailing lists or ask somebody who was there (eg. Guido), but it's easy enough to justify after the fact:

Simple increment and decrement aren't needed as much as in other languages. You don't write things like for(int i = 0; i < 10; ++i) in Python very often; instead you do things like for i in range(0, 10).

Since it's not needed nearly as often, there's much less reason to give it its own special syntax; when you do need to increment, += is usually just fine.

It's not a decision of whether it makes sense, or whether it can be done--it does, and it can. It's a question of whether the benefit is worth adding to the core syntax of the language. Remember, this is four operators--postinc, postdec, preinc, predec, and each of these would need to have its own class overloads; they all need to be specified, and tested; it would add opcodes to the language (implying a larger, and therefore slower, VM engine); every class that supports a logical increment would need to implement them (on top of += and -=).

This is all redundant with += and -=, so it would become a net loss.

---

Related Topics