-3

why the following statement is perfectly valid one

string a = "someString", b = a, c = a;

but this one does not compile

var a = "someString", b = a, c = a;

another example is here first, an error:

enter image description here

second OK:
enter image description here

I've seen a similar question here, but the context here is a little bit different:

If

var i = 2, j = 3.4;

is harder for the compiler to 'digest' (even there I don't see a problem to recognize one as int and the other as double), however

var a = "someString", b = a;

should be even less ambiguous, because:

var a = "someString", // here 'a' is inferred to 'string'

so the following

b = a;

should be also inferred to string, because a has its type already defined...

serge
  • 13,940
  • 35
  • 121
  • 205
  • They downvote because the question is unclear: in what context is the code? Class, function? Are there generics involved? – Charlieface Jan 07 '21 at 23:01
  • @Charlieface, I simplified even more the examples to be more clear – serge Jan 08 '21 at 00:15
  • 1
    The reason is the same as Eric Lippert gave on that question, it could be confusing. And that particular case is not a useful enough exception to bother designing around. – Charlieface Jan 08 '21 at 00:34
  • @Charlieface I can't agree the Eric answer fits the same situation as we have here. In the Eric situation, we have int<>double ambiguity. Here is not an ambiguity because both are clearly strings. – serge Jan 08 '21 at 00:45
  • 1
    I repeat **" not a useful enough exception to bother designing around"** – Charlieface Jan 08 '21 at 00:46
  • @Charlieface and who decides if it's enough useful or not? – serge Jan 08 '21 at 00:47
  • 1
    Microsoft, I'm afraid. If you don't like it, make your case to them, not me. I would love it too, but that's the way it is. I note that VB.net *can* do this `Dim a = "", b = a, c = 5, d= 6.5` – Charlieface Jan 08 '21 at 00:50
  • @Serge, if you think that you have a strong enough case for redesigning the feature, you can create a GitHub issue in the dotnet project. Your question on _why it is the case_ that you get the error / cannot do what you want to do _today_ is answered by Eric's comment. – namesis Jan 08 '21 at 00:55
  • 1
    I don't think nothing at all, I just asked the community to understand the situation, it's all. – serge Jan 08 '21 at 00:55
  • @Serge Fair enough! :) – namesis Jan 08 '21 at 00:56

1 Answers1

1

TLDR: It is a design decision of the C# compiler team to eliminate this feature.

As you can see, IntelliSense has already provided you with an error:

CS0819: Implicitly-typed variables cannot have multiple declarators.

The message, indicates that IntelliSense (and of course the C# compiler from which IntelliSense gets all its intelligence from) is perfectly aware of the situation and does not allow it.

Why am I saying that it is perfectly aware of the situation?

Using var to declare a variable is what we refer to as "declaring the type of a variable implicitly". "Having multiple declarators" is to make declarations like TypeName a = i, b = j. As a result, var a = "someString", b = a; (and the similar snips that you shared) can be accurately described as "using multiple declarators with implicit typing".

So C# is explicitly saying: "I know what you're trying to do but you can't". But why?

The reason is not one of an inherent limitation of the type system. It's actually not technical reason at all. The reason is due to a design decision that is described as an answer to the question that you mentioned by Eric Lippert: https://stackoverflow.com/a/4950600/10560397

Eric tries to say that because there can be ambiguity when trying to infer what sits behind var in some cases, they decided to completely eliminate the ability to do multiple declarations with implicit typing.

namesis
  • 157
  • 10
  • I can't agree the Eric answer fits the same situation as we have here. In the Eric situation, we have int<>double ambiguity. Here is not an ambiguity because all are strings. – serge Jan 08 '21 at 00:44
  • 2
    What Eric tries to say is that because there _can_ be ambiguity when trying to infer what sits behind `var` in _some_ cases, they _decided_ to _completely_ eliminate the ability to do multiple declarations with implicit typing. – namesis Jan 08 '21 at 00:51
  • that last comment would be the answer I would accept ;) – serge Jan 08 '21 at 00:54
  • however, I think if *all* of the multiple declarations are *explicitly and exactly the same type*, I think the compiler could be smart enough to differentiate such a case. – serge Jan 08 '21 at 01:00
  • Yes, of course. We are talking about a design choice to completely eliminate a feature because it can be misleading. It so happens that your decision is different to the decision of the C# compiler team. If you feel strongly about it and would like the situation to change, you could open an issue on their GitHub page (.NET Core is open source) or you can even make your own fork of the compiler. – namesis Jan 08 '21 at 01:03
  • I mark your answer as answer, however I would note the only useful part of the answer is the last phrase and the comment. And usually people reading answers don't start from the end. ;) would be great if you just move your last sentence to top (even better remove all others) – serge Jan 08 '21 at 01:10
  • 2
    @Serge: The problem with the reasoning "but my specific situation is not ambiguous so it should be allowed" is: the logical conclusion is you end up writing a very, very long list of "unambiguous scenarios", and then have to encode each of them in the compiler, and then write an error reporting mechanism that clearly explains to the user why each *not allowed* situation *might* be ambiguous, and then those people all post about it on Stack Overflow to explain why *their* situation is not really ambiguous, and... the compiler team has bigger problems to solve. – Eric Lippert Jan 11 '21 at 19:10
  • 2
    @Serge: That's why a design principle of C# is: when dividing allowed from not-allowed code, try to come up with a *simple, explainable rule* with a *clear error reporting discipline*. C# does not always succeed at this, but we aimed for a language with understandable rules, not for a language where every possible piece of unambiguous code was a legal program. – Eric Lippert Jan 11 '21 at 19:12
  • 1
    @Serge: See also https://stackoverflow.com/questions/65613857/why-cannot-return-a-nested-ref-return-result-if-the-inner-method-has-another-ref#comment116008573_65613857 for another recent post where this design principle came up. – Eric Lippert Jan 11 '21 at 23:03
  • 1
    @EricLippert observe the OP's two images. They are similar to just a new line difference. one compile another not. But I see your point. Thanks for the explanation. – serge Jan 11 '21 at 23:08