CODEWITHSUNDEEP
vb.net
Jack
Jack

Reputation: 2830

When does = perform comparison instead of assignment?

In VB.NET, there's no == operator for comparison, so the = operator serves that purpose as well as assignment. I have a function, and I want it to return the boolean result of a comparison, without storing that result in a variable:

Private Function foo() As Boolean
    Dim bar As Integer = 1
    Return bar = 2
End Function

Returns: False

OK, but what's the value of bar?

Private Function foo() As KeyValuePair(Of Boolean, Integer)
    Dim bar As Integer = 1
    Return New KeyValuePair(Of Boolean, Integer)(bar = 2, bar)
End Function

Returns: False, 1

It looks like = will perform a comparison when the statement context demands it, but is this guaranteed? That is, can I be sure that bar will never be set to 2 in this situation?

Also, I know that VB.NET doesn't allow chained inline assignments, which may be for the best. Does this odd = behavior cause any other quirks I should be aware of?

Upvotes: 4

Views: 947

Answers (4)

SSS
SSS

Reputation: 5403

Heh back in QB45 days we used to exploit the fact that "True" was the numeric value -1. So you would see code like x = 1 - x * (x < 6) (translation: increment x, but reset to 1 when it gets to 6)

Upvotes: 0

RBarryYoung
RBarryYoung

Reputation: 56745

You cannot do in-line assignments in VB, Assignment is an explicit statement:

[Let] <<target-reference>> = <<value-expression>>

The Let is optional and implicit, and hardly ever used anymore. The general rule that you can use to distinguish the [Let] command from equality testing is that for Let, no other keyword may come before the target-reference in the statement. AFAIK, in all cases of = as equality testing, there is one or more other keywords that precede it in the statement.

In your first example, the keyword Return precedes your =, so it's an equality test, and not an assignment.

In your first example you can do either:

Return 2

or

bar = 2
Return bar

As for your question "OK, but what's the value of bar?", bar still equals one.

= in VB cause no quirks. It works exactly as documented, and it always has (including its predecessor, BASIC back to 1968).

Upvotes: 3

Alexandre
Alexandre

Reputation: 498

One way to have 100% sure that the expression will be evaluated as an boolean expression is to use ()

e.g

Dim a = 2
Return (a = 1)

Since you cannot set a value to a variable wihtin the parenthesis.

What i want to say is: on an return statament for example you cant assing a value to a variable so, even if you use 

a = 1

The compilator knows that this expression only can be an boolean expression.

The same to the if statament and so on..

Upvotes: 2

user2480047
user2480047

Reputation:

If you are starting to code in VB (coming from a language like C#), you should start getting used to the peculiar VB way of doing things; which is based on the idea: as simple and intuitive for the programmer as possible. "If assignation and comparison happen always in different contexts, why not using the same operator and let the context define its exact meaning?" -> VB-way of seeing things. "No, different realities have to be accounted for by different operators. End of the discussion" -> C#-way. :)

Is this reliable? Can you blindly trust on these not-always-clear-for-a-programmer bits? Sure, VB.NET peculiarities are highly-reliable and trustworthy. You can always use = (or Is on some contexts, but VS would tell you) and be completely sure that the code will do what is expected. But the question is: are you sure that you write exactly what you want?

This last question is what, perhaps, is more criticable of VB and what might give some problems to programmers from other languages: the higher the flexibility, the more likely is that you make an error; mainly if you are used to a different format.

Regarding the chained inline assignments, I honestly don't see its true utility (and never use them in C#). Regarding other differences with respect to C#, there are plenty of them; in some cases, I think that the C# approach is better; other times, the VB.NET one. On readability/length of code, I can refer to the With Statement I have always found somehow useful which is not present in C#.

Upvotes: 3

Related Questions