What Are The Semantics Of Multiple Implicitly Typed Declarations? Part One

What Are The Semantics Of Multiple Implicitly Typed Declarations? Part One

  • Comments 21

In my earlier series on inferring a unique "best" type from a set of expressions I mentioned that one potential application of such an algorithm is in implicitly typed variables. This led to some good questions and concerns posted in the comments - questions and concerns which echo similar feedback we've been receiving from a variety of sources since we released the first technology preview of C# 3.0 last year.

I'd like to run a quick unscientific poll to see what your intuitions and expectations about implicitly typed variables with multiple declarations are. Please leave a comment describing what you think should happen here, and why you think that.

1: local variable declaration var x = 1, y = 2.0; has the same semantics as:
(a) double x = 1, y = 2.0;
(b) int x = 1; double y = 2.0;
(c) object x = 1, y = 2.0;
(d) this should be a compile-time error
(e) something else, please specify

2: local variable declaration var q = 0, r = (short)6; has the same semantics as:
(a) int q = 0; short r = 6;
(b) int q = 0, r = 6;
(c) short q = 0, r = 6;
(d) object q = 0, r = 6;
(e) this should be a compile-time error
(f) something else, please specify

Thanks! Next time I'll describe some of the pros and cons of each and what our current thinking is in this area.

  • both (e).  Var looks like it was put in for two specific purposes:  allowing types to remain anonymous in the LINQ scenario and allowing long genericized instantiations to be written more succinctly (and hopefully readably).  You'd probably wouldn't have either of these types of var declarations on a shared line.  Since var stands in for a staticly determined type anyway, there's no real purpose to make it as general as the normal concrete declarations.
  • I would definitely say it should be 1d & 2e.
    As stated before this is a typical case of subtle bugs waiting to happen. I mean the whole concept of "var" (eventhough I see why it's important) can cause subtle bugs if the user is not careful, why increase the risk? I've seen enough code with type-related bugs even when the type instantiation is explicit.
    Besides there's absolutely no good reason to not make it an error, I mean if you want two different types write var a = 1; var b = 2.0;
  • My first intuition is also 1b, 2a.  

    But since not everybody agrees about what is intuitively correct, I would actually recommend 1d, 2e.  Like some have said before, it's just a bug waiting to happen.
  • Just to follow up, I polled some veteran VB6 developers who were new to the syntax of C# and thus had no agenda or bias.  I explained the syntax, insured that they weren't thinking "variant" and the stood back to listen to the discussion.  The universal opinion is that all variables on a single "var" line should be of the same type.  The also called for a compiler error if  the implicit casting was not legal.  So, 6 votes for: 1d, 2b and 5 (overlapped) votes for "and don't ever do that in code I have to review or you're getting it back".

  • That's interesting.  In VB6 if you say

    Dim Curly, Larry, Moe as Stooge

    _of course_ that means that Curly and Larry are Variant, Moe is a Stooge.  

    My guess would be that your VB6 veterans are familiar with the pain that this "gotcha" causes and would like C# to not add a similar gotcha to the language.  

    (.NET versions of VB will treat all three as Stooges.)

  • Of course

    If you give only a number to the compiler, e.g. 2.0, the compiler will recognize the const as a double. Except you explictly specify 2.0f to make it a float. The type is clear even though it is under C# 1.0 specification.

    And I think the "var" keyword should better be used with anonymous class. You cannot specify any other class type to the variables except itself and object. We certainlly don't want the compiler to cast it to an object. Of course we also don't want compiler to change 0(int) into float, double or object.
Page 2 of 2 (21 items) 12