What is the preferred way to be explicit or allow the compiler to conclude?

Question

When is it desirable for the compiler to do its job, and when should I be explicit when declaring variable types?

Answer 1

Simply, in F #, always prefer the compiler to "do its thing." People who have written their powerful type inference system will be saddened otherwise.

Seriously, in C #, I know that there is (or was?) A discussion about when or when not to use var for derived variable types. But I believe that the problems associated with the lack of clarity were related to a community that was unfamiliar with concise, strongly typed languages ​​and feared that var was a kind of dynamic voodoo that could not be trusted. But what we have now in C #, and many times in F #, is the best of all worlds. Strong automatic printing. And the “variables” are just the top of the ice sheet. The real surprise is the conclusion of the F # signature of function types. There was some time where I believed that it was super-top, and that it would be clearer to write out the full signature. Man, you can do it fast.

Answer 2

I agree with @Stephen, let the compiler do its thing.

When you first start with a language with a language, it will look unnatural, and you will write additional type annotations, perhaps thinking that you need them for readability. You will overcome it soon; code with names of decent variables needs little writing of types everywhere; type annotations are often just super cool jamming of your algorithms.

I can only think of a couple of common troubles, so as not to describe the types. First, if you are viewing the source code as a simple text file, it may not be clear to readers what types are. However, this is mitigated in large part by the fact that tools like Visual Studio provide hover tips that show types (for example, hover over foo and a tooltip pops up indicating the type of foo ). The logic for this output is revealed by the source code of the compiler and is easily integrated into other tools, such as F # web fragments , MonoDevelop, etc. (Someone, please use the new Apache license and write plugins for github, emacs and gvim :), thanks!) As a result, you look at the code a lot, you will do it in an environment / tool where the types are available for display on demand anyway.

Secondly, it is sometimes difficult to debug type errors in the absence of type annotations. When you get a strange type inference error, you cannot understand, it may be useful to add some explicit annotations to localize the type error. Often you can see some dumbass in your code, fix it, and then remove unnecessary annotations.

Of course, there are many places where type annotations are required, since type inference cannot solve everything. See the links below for some details. You will get used to them after a while and learn to predict when you need an annotation or not.

http://lorgonblog.wordpress.com/2009/10/25/overview-of-type-inference-in-f/

Why can't the F # output method handle this?