Datasheet

Type Inference
x
25
Unfortunately, the syntax is getting tricky to parse, particularly if the constructor body is now
implicitly “inside” the class. It’s going to have diffi culty knowing what denotes a member of the
class and what denotes a local variable inside the constructor body. Even if the compiler could,
the programmer may not, so an explicit declaration of what is a member and what isn’t would be
helpful:
// This is not legal C# 3.0
class Person(firstName, lastName, age : int)
{
member FirstName { get { firstName } set; }
member LastName { get { lastName } set; }
member Age { get { age } set; }
member FullName {
get { return FirstName + “ “ + LastName; }
}
}
If the compiler’s going to infer properties, let it infer the default property implementation, a get/set
pair against a fi eld backdrop, and assign its fi rst value:
// This is not legal C# 3.0
class Person(firstName, lastName, age : int)
{
member FirstName = firstName;
member LastName = lastName;
member Age = age;
member FullName = FirstName + “ “ + LastName;
}
Methods, of course, would have similar inferential treatment:
// This is not legal C# 3.0
class Person(firstName, lastName, age : int)
{
member FirstName = firstName;
member LastName = lastName;
member Age = age;
member FullName = FirstName + “ “ + LastName;
override ToString() {
return String.Format(“{0} {1} {2}”,
FirstName, LastName, Age);
};
}
Language-wide type inference is turning out to be quite the benefi cial thing to have. Fortunately,
the compiler is still fully aware of the types of each of these constructs, so static type safety
remains viable. But if this compiler is going to continue to take burdens off the programmer’s
shoulders, then some kind of facility to address the burdens of concurrent-safe programming is
necessary.
c01.indd 25c01.indd 25 10/1/2010 3:20:39 PM10/1/2010 3:20:39 PM