tags:

views:

264

answers:

4
public bool IsValid()
{
    get { return (GetRuleViolations().Count() == 0); }
}

I'm getting this error:

; expected

What is wrong?

I'm following this tutorial: http://nerddinnerbook.s3.amazonaws.com/Part3.htm I'm not sure why they are using get.

+17  A: 

You don't need parentheses after IsValid, since it's a property not a method (presumably, since you're using a getter)

Write it like this:

public bool IsValid
{
    get { return (GetRuleViolations().Count() == 0); }
}

Alternatively, if IsValid were a method, it could look like this:

public bool IsValid()
{
    return (GetRuleViolations().Count() == 0);
}
Tim Goodman
Oh! I see now, it's just an attribute of the Area class.
Sergio Tapia
+1: A nice spot :o)
Ardman
@Ardman: Thanks :)
Tim Goodman
@Sergio Tapia - It's a Property, not an Attribute. Attributes are something different in C#.
Greg
+2  A: 

That should be written as :

public bool IsValid
{ 
    get { return (GetRuleViolations().Count() == 0); } 
} 

without the () on the first line. You'll note that it is correct on the web page you cite.

James Curran
+2  A: 

IsValid must be a property or a method.

If you want it to be a method, leave the () after IsValid and ditch the get. If you want it to be a property, remove the ().

Jay
+13  A: 

This is an interesting case where the error reporting heuristics get it wrong. What's happening here is the compiler sees

public bool IsValid() 
{ 

And says to itself "aha, here we have a public method called IsValid that takes no arguments and returns bool. I will process everything after it as a list of statements in the block of the method body.

Then it sees

get 

An interesting fact: get is not a reserved word of C#. (I discuss this fact here.)

So the compiler at this point now thinks that this is a statement beginning with the identifier "get". What could that statement possibly be? It could be a local variable declaration:

get myGet = new get();

It could be a method or delegate call:

get();

It could be an increment or decrement of a field named get.

get++;

It could be a label of a labelled statement.

get: M();

It could be the receiver of a method call:

get.M();

It could be an assignment to a field:

get = null;

It could be an event adder:

get += M;

And I'm sure there are a dozen cases I'm missing. My point is that it could be any of those things. The compiler will look at the next token to try and figure out which of those dozens of cases we're actually in. And then what the compiler actually sees is

get {

and it reasons "Hmm, that's bad. That is the start of a new block there. I know that there had to be something after the identifier get and before the start of the new block, but I don't know what it was. It could be a colon, a dot, a plus... I don't know, it could be almost anything. Is there anything I do know? Yes. I know that at the very least, there always has to be a semicolon between the end of the statement that begins with get, and the beginning of the block which follows it. Therefore I will report "missing semicolon" error because that's the best I can do at this point."

What we could have done is special-cased the situation "the get is the first thing in a method block that could be a property and is immediately followed by a left curly brace" and then report a special error in that case "hey, it looks like you're trying to write a property that takes arguments". But apparently we did not think of this situation when designing the error heuristics. That's a good one, so perhaps we'll do that in a hypothetical future version of the compiler.

Eric Lippert
If you use the error message "Hey, it looks like you're trying to write a property" they you HAVE to add a talking Paperclip offering some help :P
Michael Stum