What was the reason for Swift assignment evaluation to void?

Question

This question is about HISTORY (not your current opinions on the matter).

While reading post about dropping support for increment/decrement operators for Swift I read such text "Swift already deviates from C in that the =, += and other assignment-like operations returns Void (for a number of reasons)".

So at some time in the past developers consciously decided to evaluate assignments to void for some reasons.

And I am looking for those historical (now) reasons. Pretty much as this thread is about historical reasons for Scala.

Petiolate

Could you provide a link to the article about dropping support for increment/decrement please? I'm interested in reading it. – Noella

@FreeNickname, sure, take a look: github.com/apple/swift-evolution/blob/master/proposals/… – Petiolate

in C you can use something like if i=1 {}. the result of an assignment returns value which you can use. in swift such statements will not compile and the reason (i think so) is to avoid unwanted side effect. i can agree with this idea, on the opposite side i really don't see, why ++i, i++. --i, i-- should be removed from the language. i read the article at least twice and it is still not very clear to me. – Brandybrandyn

@user3441734, it might be the reason, however I don't think it is. Because in Swift only boolean expressions are accepted in if, if I'm not mistaken. So even if i = 1 returned if, if i = 1 {} wouldn't compile, since in Swift 1 is not a boolean value. @greenoldman, thank you for the link) – Noella

I can't talk specifically about Swift, but some people consider using an expression for both its value and its side-effect a bad practice, because such code is hard to understand. It can also lead to code like i = ++i + i++;, which has undefined behavior in C and C++. – Linker

Answer 1

At least one reason is to be safer in comparison operations. When writing in C, Objective-C, etc., how many times have you written this:

if (x = 2)

instead of

if (x == 2)

Newer versions of compilers have introduced specific warnings for the above case, but wow has that one missing equal sign caused hard-to-identify bugs in my code over the years.

With the Swift type system, this would be less of a problem, since the returned value would most likely not comply to the BooleanType protocol, but if it did (if x = false), you might still hit these bugs. A lot of Swift is designed to eliminate common causes of bugs that people have encountered, including this one.

This is stated in the Swift Programming Language book, under "Basic Operators":

Unlike the assignment operator in C and Objective-C, the assignment operator in Swift does not itself return a value. The following statement is not valid:

if x = y {
    // this is not valid, because x = y does not return a value
}

This feature prevents the assignment operator (=) from being used by accident when the equal to operator (==) is actually intended. By making if x = y invalid, Swift helps you to avoid these kinds of errors in your code.

Kinney

I never in my life (30+ years as developer) made this error, but I wrote a lot of x=y=2 like code. I feel punished for the errors of others :-) – Cryptonymous