Use of var keyword in C#

I still think var can make code more readable in some cases. If I have a Customer class with an Orders property, and I want to assign that to a variable, I will just do this:

var orders = cust.Orders;

I don't care if Customer.Orders is IEnumerable<Order>, ObservableCollection<Order> or BindingList<Order> - all I want is to keep that list in memory to iterate over it or get its count or something later on.

Contrast the above declaration with:

ObservableCollection<Order> orders = cust.Orders;

To me, the type name is just noise. And if I go back and decide to change the type of the Customer.Orders down the track (say from ObservableCollection<Order> to IList<Order>) then I need to change that declaration too - something I wouldn't have to do if I'd used var in the first place.

I use var extensively. There has been criticism that this diminishes the readability of the code, but no argument to support that claim.

Admittedly, it may mean that it's not clear what type we are dealing with. So what? This is actually the point of a decoupled design. When dealing with interfaces, you are emphatically not interested in the type a variable has. var takes this much further, true, but I think that the argument remains the same from a readability point of view: The programmer shouldn't actually be interested in the type of the variable but rather in what a variable does. This is why Microsoft also calls type inference “duck typing.”

So, what does a variable do when I declare it using var? Easy, it does whatever IntelliSense tells me it does. Any reasoning about C# that ignores the IDE falls short of reality. In practice, every C# code is programmed in an IDE that supports IntelliSense.

If I am using a var declared variable and get confused what the variable is there for, there's something fundamentally wrong with my code. var is not the cause, it only makes the symptoms visible. Don't blame the messenger.

Now, the C# team has released a coding guideline stating that var should only be used to capture the result of a LINQ statement that creates an anonymous type (because here, we have no real alternative to var). Well, screw that. As long as the C# team doesn't give me a sound argument for this guideline, I am going to ignore it because in my professional and personal opinion, it's pure baloney. (Sorry; I've got no link to the guideline in question.)

Actually, there are some (superficially) good explanations on why you shouldn't use var but I still believe they are largely wrong. Take the example of “searchabililty”: the author claims that var makes it hard to search for places where MyType is used. Right. So do interfaces. Actually, why would I want to know where the class is used? I might be more interested in where it is instantiated and this will still be searchable because somewhere its constructor has to be invoked (even if this is done indirectly, the type name has to be mentioned somewhere).

From Eric Lippert, a Senior Software Design Engineer on the C# team:

Why was the var keyword introduced?

There are two reasons, one which exists today, one which will crop up in 3.0.

The first reason is that this code is incredibly ugly because of all the redundancy:

Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();

And that's a simple example – I've written worse. Any time you're forced to type exactly the same thing twice, that's a redundancy that we can remove. Much nicer to write

var mylists = new Dictionary<string,List<int>>();

and let the compiler figure out what the type is based on the assignment.

Second, C# 3.0 introduces anonymous types. Since anonymous types by definition have no names, you need to be able to infer the type of the variable from the initializing expression if its type is anonymous.

Emphasis mine. The whole article, C# 3.0 is still statically typed, honest!, and the ensuing series are pretty good.

This is what var is for. Other uses probably will not work so well. Any comparison to JScript, VBScript, or dynamic typing is total bunk. Note again, var is required in order to have certain other features work in .NET.

I think the use of var should be coupled with wisely-chosen variable names.

I have no problem using var in a foreach statement, provided it's not like this:

foreach (var c in list) { ... }

If it were more like this:

foreach (var customer in list) { ... }

... then someone reading the code would be much more likely to understand what "list" is. If you have control over the name of the list variable itself, that's even better.

The same can apply to other situations. This is pretty useless:

var x = SaveFoo(foo);

... but this makes sense:

var saveSucceeded = SaveFoo(foo);

Each to his own, I guess. I've found myself doing this, which is just insane:

var f = (float)3;

I need some sort of 12-step var program. My name is Matt, and I (ab)use var.

We've adopted the ethos "Code for people, not machines", based on the assumption that you spend multiple times longer in maintenance mode than on new development.

For me, that rules out the argument that the compiler "knows" what type the variable is - sure, you can't write invalid code the first time because the compiler stops your code from compiling, but when the next developer is reading the code in 6 months time they need to be able to deduce what the variable is doing correctly or incorrectly and quickly identify the cause of issues.

Thus,

var something = SomeMethod();

is outlawed by our coding standards, but the following is encouraged in our team because it increases readability:

var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
   DoWork( item ); 
}

One specific case where var is difficult: offline code reviews, especially the ones done on paper.

You can't rely on mouse-overs for that.

I don't see what the big deal is..

var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!

You still have full intellisense on 'something', and for any ambiguous case you have your unit tests, right? ( do you? )

It's not varchar, it's not dim, and it's certainly not dynamic or weak typing. It is stopping maddnes like this:

List<somethinglongtypename> v = new List<somethinglongtypename>();

and reducing that total mindclutter to:

var v = new List<somethinglongtypename>();

Nice, not quite as nice as:

v = List<somethinglongtypename>();

But then that's what Boo is for.

Given how powerful Intellisense is now, I am not sure var is any harder to read than having member variables in a class, or local variables in a method which are defined off the visible screen area.

If you have a line of code such as

IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

Is is much easier or harder to read than:

var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

I think the key thing with VAR is to only use it where appropriate i.e. when doing things in Linq that it facilitates (and probably in other cases).

If you've got a type for something in the then you should use it - not to do so is simple laziness (as opposed to creative laziness which is generally to be encouraged - good programmers oft work very hard to be lazy and could be considered the source of the thing in the first place).

A blanket ban is as bad as abusing the construct in the first place but there does need to be a sensible coding standard.

The other thing to remember is that its not a VB type var in that it can't change types - it is a strongly typed variable its just that the type is inferred (which is why there are people that will argue that its not unreasonable to use it in, say, a foreach but I'd disagree for reasons of both readability and maintainability).

I suspect this one is going to run and run (-:

Murph

Stolen from the post on this issue at CodingHorror:

Unfortunately, you and everyone else pretty much got it wrong. While I agree with you that redundancy is not a good thing, the better way to solve this issue would have been to do something like the following:

Nicholas Paldino .NET/C# MVP on June 20, 2008 08:00 AM

I guess if your main concern is to have to type less -- then there isn't any argument that's going to sway you from using it.

If you are only going to ever be the person who looks at your code, then who cares? Otherwise, in a case like this:

var people = Managers.People

it's fine, but in a case like this:

var fc = Factory.Run();

it short circuits any immediate type deductions my brain could begin forming from the 'English' of the code.

Otherwise, just use your best judgment and programming 'courtesy' towards others who might have to work on your project.

@aku: One example is code reviews. Another example is refactoring scenarios.

Basically I don't want to go type-hunting with my mouse. It might not be available.

It's a matter of taste. All this fussing about the type of a variable disappears when you get used to dynamically typed languages. That is, if you ever start to like them (I'm not sure if everybody can, but I do).

C#'s var is pretty cool in that it looks like dynamic typing, but actually is static typing - the compiler enforces correct usage.

The type of your variable is not really that important (this has been said before). It should be relatively clear from the context (its interactions with other variables and methods) and its name - don't expect customerList to contain an int...

I am still waiting to see what my boss thinks of this matter - I got a blanket "go ahead" to use any new constructs in 3.5, but what will we do about maintenance?

In your comparison between IEnumerable<int> and IEnumerable<double> you don't need to worry - if you pass the wrong type your code won't compile anyway.

There's no concern about type-safety, as var is not dynamic. It's just compiler magic and any type unsafe calls you make will get caught.

Var is absolutely needed for Linq:

var anonEnumeration =
    from post in AllPosts()
    where post.Date > oldDate
    let author = GetAuthor( post.AuthorId )
    select new { 
        PostName = post.Name, 
        post.Date, 
        AuthorName = author.Name
    };

Now look at anonEnumeration in intellisense and it will appear something like IEnumerable<'a>

foreach( var item in anonEnumeration ) 
{
    //VS knows the type
    item.PostName; //you'll get intellisense here

    //you still have type safety
    item.ItemId;   //will throw a compiler exception
}

The C# compiler is pretty clever - anon types generated separately will have the same generated type if their properties match.

Outside of that, as long as you have intellisense it makes good sense to use var anywhere the context is clear.

//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();

//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();

//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;

I guess it depends on your perspective. I personally have never had any difficulty understanding a piece of code because of var "misuse", and my coworkers and I use it quite a lot all over. (I agree that Intellisense is a huge aid in this regard.) I welcome it as a way to remove repetitive cruft.

After all, if statements like

var index = 5; // this is supposed to be bad

var firstEligibleObject = FetchSomething(); // oh no what type is it
                                            // i am going to die if i don't know

were really that impossible to deal with, nobody would use dynamically typed languages.

To me, the antipathy towards var illustrates why bilingualism in .NET is important. To those C# programmers who have also done VB .NET, the advantages of var are intuitively obvious. The standard C# declaration of:

List<string> whatever = new List<string>();

is the equivalent, in VB .NET, of typing this:

Dim whatever As List(Of String) = New List(Of String)

Nobody does that in VB .NET, though. It would be silly to, because since the first version of .NET you've been able to do this...

Dim whatever As New List(Of String)

...which creates the variable and initializes it all in one reasonably compact line. Ah, but what if you want an IList<string>, not a List<string>? Well, in VB .NET that means you have to do this:

Dim whatever As IList(Of String) = New List(Of String)

Just like you'd have to do in C#, and obviously couldn't use var for:

IList<string> whatever = new List<string>();

If you need the type to be something different, it can be. But one of the basic principles of good programming is reducing redundancy, and that's exactly what var does.

Use it for anonymous types - that's what it's there for. Anything else is a use too far. Like many people who grew up on C, I'm used to looking at the left of the declaration for the type. I don't look at the right side unless I have to. Using var for any old declaration makes me do that all the time, which I personally find uncomfortable.

Those saying 'it doesn't matter, use what you're happy with' are not seeing the whole picture. Everyone will pick up other people's code at one point or another and have to deal with whatever decisions they made at the time they wrote it. It's bad enough having to deal with radically different naming conventions, or - the classic gripe - bracing styles, without adding the whole 'var or not' thing into the mix. The worst case will be where one programmer didn't use var and then along comes a maintainer who loves it, and extends the code using it. So now you have an unholy mess.

Standards are a good thing precisely because they mean you're that much more likely to be able to pick up random code and be able to grok it quickly. The more things that are different, the harder that gets. And moving to the 'var everywhere' style makes a big difference.

I don't mind dynamic typing, and I don't mind implict typing - in languages that are designed for them. I quite like Python. But C# was designed as a statically explicitly-typed language and that's how it should stay. Breaking the rules for anonymous types was bad enough; letting people take that still further and break the idioms of the language even more is something I'm not happy with. Now that the genie is out of the bottle, it'll never go back in. C# will become balkanised into camps. Not good.

Many time during testing, I find myself having code like this:

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);

Now, sometimes, I'll want to see what the SomeOtherThing itself contains, SomeOtherThing is not the same type that CallMethod() returns. Since I'm using var though, I just change this:

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();

to this:

var something = myObject.SomeProperty.SomeOtherThing;

Without var, I'd have to keep changing the declared type on the left hand side as well. I know it's minor, but it's extremely convenient.

For the afficionados that think var saves time, it takes less keystrokes to type:

StringBuilder sb = new StringBuilder();

than

var sb = new StringBuilder();

Count em if you don't believe me...

19 versus 21

I'll explain if I have to, but just try it... (depending on the current state of your intellisense you may have to type a couple more for each one)

And it's true for every type you can think of!!

My personal feeling is that var should never be used except where the type is not known because it reduces recognition readabiltiy in code. It takes the brain longer to recognize the type than a full line. Old timers who understand machine code and bits know exactly what I am talking about. The brain processes in parallel and when you use var you force it to serialize its input. Why would anyone want to make their brain work harder? That's what computers are for.

I split var all over the places, the only questionable places for me are internal short types, e.g. I prefer int i = 3; over var i = 3;

It can certainly make things simpler, from code I wrote yesterday:

var content  = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }

This would have be extremely verbose without var.

Addendum: A little time spent with a language with real type inference (e.g. F#) will show just how good compilers are at getting the type of expressions right. It certainly has meant I tend to use var as much as I can, and using an explicit type now indicates that the variable is not of the initialising expression's type.

I had the same concern when I started to use var keyword.
However I got used to it over time and not going to go back to explicit variable types. Visual Studio's compiler\intellisense are doing a very good job on making work with implicitly typed variables much easier.

I think that following proper naming conventions can help you to understand code much better then explicit typing.

It seems to be same sort of questions like "shoud I use prefixes in variable names?".
Stick with good variable names and let the compiler think on variable types.

Someone doesn't like criticism of var.. All answers downmodded.. oh well..

@Jon Limjap: I know. :) What I meant was that the readability is degraded like it is in VB6. I don't like to rely on Intellisense to figure out what type a given variable is. I want to be able to figure it out using the source alone.

Naming conventions doesn't help either - I already use good names. Are we going back to prefixing?

I use var whenever possible.

The actual type of the local variable shouldn't matter if your code is well written (i.e., good variable names, comments, clear structure etc.)

After just converting over to the 3.0 and 3.5 frameworks I learned about this keyword and decided to give it a whirl. Before committing any code I had the realization that it seemed backwards, as in going back toward an ASP syntax. So I decided to poke the higher ups to see what they thought.

They said go ahead so I use it.

With that said I avoid using it where the type requires some investigation, like this:

var a = company.GetRecords();

Now it could just be a personal thing but I immediately cant look at that and determine if its a collection of Record objects or a string array representing the name of records. Whichever the case I believe explicit declaration is useful in such an instance.

Static typing is about contracts, not source code. The idea there is a need to have the static information on a single line of what "should" be a small method. Common guidelines recommend rarely exceeding 25 lines per method.

If a method is large enough that you can't keep track of a single variable within that method, you are doing something else wrong that would make any criticism of var pale in comparison.

Actually, one of the great arguments for var is that it can make refactoring simpler because you no longer have to worry that you made your declaration overly restrictive (i.e. you used List<> when you should have used IList<>, or IEnumerable<>). You still want to think about the new methods signature, but at least you won't have to go back and change your declarations to match.

There is bound to be disagreement near the edge cases, but I can tell you my personal guidelines.

I look at these the criteria when I decide to use var:

• The type of the variable is obvious [to a human] from the context
• The exact type of the variable is not particularly relevant [to a human]
  [e.g. you can figure out what the algorithm is doing without caring about what kind of container you are using]
• The type name is very long and interrupts the readability of the code (hint: usually a generic)

Conversely, these situations would push me to not use var:

• The type name is relatively short and easy to read (hint: usually not a generic)
• The type is not obvious from the initializer's name
• The exact type is very important to understand the code/algorithm
• On class hierarchies, when a human can't easily tell which level of the hierarchy is being used

Finally, I would never use var for native value types or corresponding nullable<> types (int, decimal, string, decimal?, ...). There is an implicit assumption that if you use var, there must be "a reason".

These are all guidelines. You should also think also about the experience and skills of your coworkers, the complexity of the algorithm, the longevity/scope of the variable, etc, etc.

Most of the time, there is no perfect right answer. Or, it doesn't really matter.

[Edit: removed a duplicate bullet]

In our office, our CTO has categorically banned the use of the var keyword, for the same reasons that you have stated.

Personally I find the use of var only valid in new object declarations, since the type of the object is obvious in the statement itself.

For LINQ queries, you can resolve results to:

IEnumerable<TypeReturnedBySelectObject>

@erlando, out of curiosity, why do you need to know the variable's type looking at the source code?

In my practice I found that variable type is matter for me only at the time I'm using it in the code.

If I'm trying to do some inappropriate operation on someVar compiler gladly gives me an error\warning.

I really don't care what type someVar has if I understand why it's being used it the given context.

I use var in the following situations:

1. When I have to (result is anonymous)

2. When the type is on the same line as the code, e.g.

   var emp = new Employee();

Its obvious we want an Employee (because we're creating a new Employee object), so how is

Employee emp = new Employee() any more obvious?

I do NOT use var when the type cannot be inferred, e.g.

var emp = GetEmployee();

Because the return type is not immediately obvious (is at an Employee, an IEmployee, something that has nothing to do with an Employee object at all, etc?).

I have to agree with Matt Hamilton.

Var can make your code much more readable and understandable when used with good variable names. But var can also make your code as impossible to read and understand as Perl when used badly.

A list of good and bad uses of var isn't really going to help much either. This is a case for common sense. The larger question is one of readability vs. write-ability. Lots of devs don't care if their code is readable. They just don't want to type as much. Personally I'm a read > write guy.

kronoz - in that case (overloads for both) would it matter? If you have two overloads that took the different types you would essentially be saying that either can be passed and do the same thing.

You shouldn't have two overloads that do completely different actions depending on the types passed.

While you might get some confusion in that instance it would still be entirely type safe, you'd just have someone calling the wrong method.

I don't understand why people start debates like this. It really serves no purpose than to start flame wars at then end of which nothing is gained. Now if the C# team was trying to phase out one style in favor of the other, I can see the reason to argue over the merits of each style. But since both are going to remain in the language, why not use the one you prefer and let everybody do the same. It's like the use of everybody's favorite ternary operator: some like it and some don't. At the end of the day, it makes no difference to the compiler.

This is like arguing with your siblings over which is your favorite parent: it doesn't matter unless they are divorcing!

I find that using the var keyword actually makes the code more readable because you just get used to skipping the 'var' keyword. You don't need to keep scrolling right to figure out what the code is doing when you really don't care about what the specific type is. If I really need to know what type 'item' is below, I just hover my mouse over it and Visual Studio will tell me. In other words, I would much rather read

foreach( var item in list ) { DoWork( item ); }

over and over than

foreach( KeyValuePair<string, double> entry in list ) { DoWork( Item ); }

when I am trying to digest the code. I think it boils down to personal preference to some extent. I would rely on common sense on this one -- save enforcing standards for the important stuff (security, database use, logging, etc.)

-Alan.

I think people do not understand the var keyword. They confuse it with the Visual Basic / JavaScript keyword, which is a different beast all toghether.

Many people think the var keyword implies weak typing (or dynamic typing), while in fact c# is and remains strongly typed.

If you consider this in javascript:

var something = 5;

you are allowed to:

something = "hello";

In the case of c#, the compiler would infer the type from the first statement, causing something to be of type "int", so the second statement would result in an exception.

People simply need to understand that using the var keyword does not imply dynamic typing and then decide how far they want to take the use of the var keyword, knowing it will have absolutely no difference as to what will be compiled.

Sure the var keyword was introduced to support anonymous types, but if you look at this:

LedDeviceController controller = new LedDeviceController("172.17.0.1");

It's very very verbose, and I'm sure this is just as readable, if not more:

var controller = new LedDeviceController("172.17.0.1");

The result is exactly the same, so yes I use it throughout my code

UPDATE:

Maybe, just maybe... they should have used another keyword, then we would not be having this discussion... perhaps the "infered" keyword instead of "var"

Arriving a bit late at this discussion, but I'd just like to add a thought.

To all those who are against type inference (because that's what we're really talking about here), what about lambda expressions? If you insist on always declaring types explicitly (except for anonymous types), what do you do with lambdas? How does the "Don't make me use mouseover" argument apply to var but not to lambdas?

UPDATE

I've just thought of one argument against 'var' which I don't think anyone has mentioned yet, which is that it 'breaks' "Find all references", which could mean (for example) that if you were checking out usage of a class before refactoring, you would miss all the place where the class was used via var.

@erlando,

Talking about refactoring it seems to be much easier to change variable type by assigning instance of new type to one variable rather then changing it in multiple places, isn't it ?

As for code review I see no big issues with var keyword. During code review I prefer to check code logic rather variable types. Of course there might be scenarios where developer can use inappropriate type but I think that number of such cases is so small it wouldn't be a reason for my to stop using var keyword.

So I repeat my question. Why does variable type matter to you?

@Keith -

In your comparison between IEnumerable<int> and IEnumerable<double> you don't need to worry - if you pass the wrong type your code won't compile anyway.

That isn't quite true - if a method is overloaded to both IEnumerable<int> and IEnumerable<double> then it may silently pass the unexpected inferred type (due to some other change in the program) to the wrong overload hence causing incorrect behaviour.

I suppose the question is how likely it is that this sort of situation will come up!

I guess part of the problem is how much confusion var adds to a given declaration - if it's not clear what type something is (despite being strongly typed and the compiler understanding entirely what type it is) someone might gloss over a type safety error, or at least take longer to understand a piece of code.

var is essential for anonymous types (as pointed out in one of the previous responses to this question).

I would categorise all other discussion of its pros and cons as "religious war". By that I mean that a comparison and discussion of the relative merits of...

var i = 5;
int j = 5;

SomeType someType = new SomeType();
var someType = new SomeType();

...is entirely subjective.

Implicit typing means that there is no runtime penalty for any variable being declared using the var keyword, so it comes down to being a debate about what makes the developers happy.

I don't use var as it goes against the roots of C# - C/C++/Java. Even though it's a compiler trick it makes the language feel like it's less strongly typed. Maybe 20+ years of C have engrained it all into our (the anti-var people's) heads that we should have the type on both the left and right side of the equals.

Having said that I can see its merits for long generic collection definitions and long class names like the codinghorror.com example, but elsewhere such as string/int/bool I really can't see the point. Particularly

foreach (var s in stringArray)
{

}

a saving of 3 characters!

The main annoyance for me is not being able to see the type that the var represents for method calls, unless you hover over the method or F12 it.

VS2008 w/resharper 4.1 has correct typing in the tooltip when you hover over "var" so I think it should be able to find this when you look for all usages of a class.

Haven't yet tested that it does that yet though.

Depends, somehow it makes the code look 'cleaner', but agree it makes it more unreadable to...

It can make code simpler and shorter, especially with complicated generic types and delegates.

Also, it makes variable types easier to change.

var is great when you don't want to repeat yourself. For example, I needed a data structure yesterday that was similar to this. Which representation do you prefer?

Dictionary<string, Dictionary<string, List<MyNewType>>> collection = new Dictionary<string, Dictionary<string, List<MyNewType>>>();

or

var collection = new Dictionary<string, Dictionary<string, List<MyNewType>>>();

Note that there is little ambiguity introduced by using var in this example. However, there are times when it wouldn't be such a good idea. For example, if I used var as in the following,

var value= 5;

when I could just write the real type and remove any ambiguity in how 5 should be represented.

double value = 5;

I don't think var per say is a terrible language feature, as I use it daily with code like what Jeff Yates described. Actually, almost everytime I use var is because generics can make for some extremely wordy code. I live verbose code but generics take it a step too far.

That said, I (obviously... ) think var is ripe for abuse. If code gets to 20+ lines in a method with vars littered through out, you will quickly make maintenance a nightmare. Additionally, var in a tutorial is incredibly counter intuitive and generally is a giant no-no in my books.

On the flipside, var is an "easy" feature that new programmers are going to latch onto and love. Then, within a few minutes/hours/days hit a massive roadblock when they start hitting the limits. "Why can't I return var from functions?" That kind of question. Also, adding a pseudo dynamic type to a strongly typed language is something that can easily trip up a new developer. In the long run, I think the var keyword will actually make c# harder to learn for new programmers.

That said, as an experienced programmer I do use var, mostly when dealing with generics ( and obviously anonymous types ). I do hold by my quote, I do believe var will be one of the worst abused c# features.

From Essential LINQ:

It is best not to explicitly declare the type of a range variable unless absolutely necessary. For instance, the following code compiles cleanly, but the type could have been inferred by the compiler without a formal declaration:

List<string> list = new List<string> { "LINQ", "query", "adventure" };
var query = from string word in list
      where word.Contains("r")
      orderby word ascending
      select word;

Explicitly declaring the type of a range variable forces a behind-the-scenes call to the LINQ Cast operator. This call may have unintended consequences and may hurt performance. If you encounter performance problems with a LINQ query, a cast like the one shown here is one possible place to begin looking for the culprit. (The one exception to this rule is when you are working with a nongeneric Enumerable, in which case you should use the cast.)