Deprecate the var keyword

[axic]

I do not think there is any proper legitimate use left for the var keyword therefore I suggest we remove it.

In for loops already a type is suggested, instead of tuple declarations tuple assignments can be used and there is no need for the var for functions as function types can be used now.

Is there any other use case for var?

In #2558 I proposed to replace it with auto, but this issue would override that and just drop it.

[axic]

@chriseth any arguments for keeping var?

[chriseth]

No, I am not a big fan of auto in C++ either.

[axic]

The task here is to extend libsolidity/analysis/SyntaxChecker with a visitor for VariableDeclaration where the typeName is empty (means "var").

The compiler should emit a warning for such instances, unless the experimental mode V050 is turned on, in which case it should be an error.

[briandsutton]

Hi, I'm trying to understand something here. I understand, the use of 'var' keyword was deprecated in solidity version 0.4.20 (https://github.com/ethereum/solidity/releases/tag/v0.4.20), however the documentation for tuple assignments for that version shows the use of the 'var' keyword (https://solidity.readthedocs.io/en/v0.4.20/control-structures.html#assignment).

Is this use still correct? In case it's not, how should it be used?

[axic]

@briandsutton thanks for noticing, it was left by mistake. Tuple assignments will be changed as proposed in #3314.

[jtakalai]

So... what's the resolution on how tuple assignments are done in the future? Instead of

var (,a,,,,b,,,,,c,,,,,) = crazyfunction()

we'd have to first introduce the types like so:

uint a;
string b;
bytes32 c;
(,a,,,,b,,,,,c,,,,,) = crazyfunction()

I don't see how that is an improvement. Even the following would be neat enough:

(,uint a,,,,string b,,,,,bytes32 c,,,,,) = crazyfunction()

[OTTTO]

potentially var could only be used for tuple destructuring.

[ellis2323]

So what's the fix for the 0.4.21. I have many functions like:
var (,a,,,,b,,,,,c,,,,,) = crazyfunction()
auto doesn't work. And no fix in the documentation.

[jtakalai]

@OTTTO right, I'm not protesting deprecating var per se, just its one and only very nice use case probably should be re-thought somehow...

[JohnAllen]

@ellis2323 #3301 (comment)

[dukei]

How about var automatically preserves storage of the variable?
When using var the type is automatically inferred so you should not specify it explicitly.

For example there is struct OuterType.InnerType and function foo() returns (OuterType.InnerType storage)

With var I can write:

var x = foo();

Without var I should write:

OuterType.InnerType storage x = foo();

The latter case is very verbose. I would prefer var in this case.

What is about this usecase?

[chriseth]

@dukei we want to introduce type aliases for this case. For now, please bear with verbosity - I'm a big fan of the Zen of Python: https://www.python.org/dev/peps/pep-0020/#id3

[jtakalai]

@chriseth except this isn't Python. Python doesn't require explicit type declarations, so Python's zen wouldn't be broken by disallowing automatic type inference since there is none to begin with -___-

The whole point of static type checking is that the pieces won't fit wrong, even if you don't explicitly spell out the types. Also, have you considered this form of tuple de-construction?

(,uint a,,,,string b,,,,,bytes32 c,,,,,) = crazyfunction()

[chriseth]

@jtakalai yes, this is exactly what we will be implementing for the next release.

[ghost]

OuterType.InnerType storage x = foo();
var x = foo();

I want the ability to change functions. I don't believe functions are a type. It is a grave mistake to depreciate var. Correct me if I'm wrong.

[chriseth]

There are function types.