Hacker News Reader

Comment by JoeAltmaier | Hacker News Reader

Unexpected conversions can add bugs. Putting a string into a table that was implicitely integer - if your string doesn't start with digits it gets converted to zero. Was that what you intended? Did you think the table would hold a string?

View on HN

Type inference in C# with the var keyword doesn't work like a dynamic language like javascript. It works by simply using var as a placeholder for whatever type the right hand side returns, which is determined at compile time.

So the type depends upon the initial values, which might not be representative of your full intent? A list of strings doesn't guarantee you won't want later to put something else in there.

I guess you'd just have to declare it explicitly in that case.

But you could explicitly declare the string table and still try to put an integer into it. Your example isn't an issue of type inference, it's an issue with the developer not properly tracking what variables store what types in his/her own code.

Yep, like if you wanted to put a list behind an IEnumerable interface or something like that, instead of an actual list. It's just a very useful shortcut for the thing you want to do 90% of the time.

Why would you want to put anything other than a string in a list of strings ? That's just looking for trouble IMHO.

So it's not actually the type inference that's the problem -- it's developers who carelessly define implicit conversion operators on their classes.

Strings have built-in conversion, right?

The only built-in implicit conversions in C# are for numerics, and there isn't a loss in precision for those (with the exception of int/uint/long/ulong -> float and long/ulong -> double, where there is a loss of precision).

http://msdn.microsoft.com/en-us/library/y5b434w4.aspx

     int i = "5";

would not work.

Not the kind you seem to be thinking of.

Implicit conversions != Type inference

Reply on news.ycombinator.com