What about:
public class Person
{
public Person()
{
this.Name = "Scott Guthrie";
this.Age = 35;
}
public string Name { get; set; }
public string Age { get; set; }
}
in practice, that comes down to the same and isn't that much extra work, I believe. But perhaps, for once in a long while, VB looks clearer then C#... ;-)
EDIT (rationale):
You were asking for the rationale in your last comment under (and in) your original question. Thinking out loud, I think that the principle in C# that initialization code goes to one place and one place only, namely the constructor, is the reason for this decision. Adding another place where you have to look to find initialization code makes debugging harder and the code less clear.
Obviously, an inline initialization value cannot contain other initializations or calculations (at least, very limited). While I agree that it can be more concise in the VB way, I would understand the C# team and Anders Hejlsberg if they said that they consider it a bigger advantage to have one place for initialization.
EDIT: here's what Microsoft says about it. In short, not for C# 4.0, but perhaps C# 5.0? Also:
"It is not as easy as it sounds though:
the next thing you want is for the
constructor to initialize the backing
field, but it can only do that through
the setter, which might not be what
you want."
and (just a commenter):
"Lack of initialization or constructor
control makes the feature practically
worthless for properties returning a
reference type."
