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.