Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Restrictions on implicit typing

Tags:

c#

types

In his book, Jon Skeet refers to 7 restrictions on implicit typing. I need clarification on the last two:

A. The type you want the variable to have is the compile-time type of the initialization expression.
B. The initialization expression doesn't involve the variable being declared.

The book covers material in the same order it was released (C# 2 before C# 3). At this point C# 4 has not been introduced so I make the assumption that A does not refer to dynamic. So, when would the compile-time type be different from the execution time type of the initialization expression?

As for B, when can an initialization expression involve the variable being declared?

like image 361
P.Brian.Mackey Avatar asked May 23 '12 18:05

P.Brian.Mackey


People also ask

What is the difference between explicit typed variables and implicit typed variables?

Explicit: stated clearly and in detail, leaving no room for confusion or doubt. Implicit: implied though not plainly expressed.

What is a variable of implicit type and what is its scope?

Implicitly typed variables are those variables which are declared without specifying the . NET type explicitly. In implicitly typed variable, the type of the variable is automatically deduced at compile time by the compiler from the value used to initialize the variable.

Does C# have explicit variable declaration?

You can set different preferences of using 'var' or explicit type for different types: For built-in types — applies to C# built-in types. For simple types — applies to types without generic parameters. Elsewhere — applies to generic types and deconstruction declarations.

Why should I use var in C#?

The use of var helps simplify your code, but its use should be restricted to cases where it is required, or when it makes your code easier to read. For more information about when to use var properly, see the Implicitly typed local variables section on the C# Coding Guidelines article.


2 Answers

Regarding B, Henk gave a perfect answer (edit: it's now removed), although I find it peculiar that int x = x = 1; compiles. (I would've thought x isn't considered declared until after the initializer. Oh, well.) His answer was:

int x = x = 1;   // Compiles
var y = y = 2;   // Does not compile

Regarding A and your question as to when the compile time type wouldn't match the execution time type, here's an example where they would differ:

var foo = fooFactory.GetFoo();

... and that method on fooFactory is implemented as ....

public FooBase GetFoo() {
    return new FooSubtype();
}

Here, foo's type is FooBase (which may be an interface, abstract class, or unsealed concrete class), and (without casting) only its features are available. Clearly, FooSubtype implements or inherits from FooBase.

The type that foo holds at runtime can be discerned here only because I show the implementation of GetFoo(), but it isn't inspected by the compiler. In fact, the implementation may not even be available (could be in another assembly) or it may vary (could be virtual). For determining the compile-time type of GetFoo(), and therefore of foo, only the method declaration is relevant.

like image 106
Keith Robertson Avatar answered Nov 11 '22 21:11

Keith Robertson


My thoughts for A:

It's not that the compile-time is different from the execution type, since even if the execution type is not the same as the compile type (like in any method whose return type is an abstract type), you cannot declare the variable with the execution type anyway with explicit typing.

But you could want to declare the variable with a more abstract static type, even if the real dynamic type can be defined at compile-time. Consider for example:

ISomething a = new MyOwnSomething();

Why would you want to do this? If your MyNewSomething implements ISomething explicitly then you would have to make a cast to use it like an ISomething if declared on a var. Here the cast is still been done, but you don't see the rather ugly:

var a = new MyOwnSomething();
((ISomething)a).Whatever();

A more contrived example is that the initialization code can change later on but and you want to make sure that from this point on you only use a as an ISomething, and never see the details of the MyOwnSomething type, or other interfaces it may be implementing, so that changes on the initialization type won't break the code.

like image 35
Alejandro Piad Avatar answered Nov 11 '22 21:11

Alejandro Piad