什么时候让编译器做它的事情，什么时候在声明变量类型时我应该是明确的呢？
答案 0 :(得分：8)
很简单，在F＃中，总是更喜欢让编译器“做它的事情”。编写强大的类型推理系统的人会感到难过。
严肃地说，在C＃中，我知道（或者是？）关于何时或何时不使用var进行变量类型的辩论。但我认为那里缺乏明确性的担忧源于一个不熟悉简洁的强类型语言的社区，并担心var是一种不可信赖的动态伏都教。但是我们现在在C＃中所拥有的，以及在F＃中多次，是所有世界中最好的。强大的自动打字功能。而“变量”只是冰城的一角。真正令人惊讶的是F＃对函数类型签名的推断。在那里有一段时间我认为这是过分的，并且写出完整的签名会更清楚。伙计，你快点过来。
答案 1 :(得分：4)
我同意@Stephen，让编译器“做它的事情”。
当您第一次使用类型推断语言时，这会感觉不自然，您会编写额外的类型注释，或许认为您需要它们以便于阅读。你很快就会克服它;具有良好变量名称的代码几乎不需要在任何地方拼写出类型，类型注释通常只会使算法混乱。
我只能想到一些不用拼写出类型的一般性损害。首先，如果您将源代码视为纯文本文件，那么对于读者来说，类型是什么并不明显。但是，这很大程度上是因为像Visual Studio这样的工具提供了显示类型的悬停工具提示（例如，将鼠标悬停在foo上，弹出工具提示，显示foo的类型）。编译器源代码公开了执行此推理的逻辑，并且已经轻松地集成到其他工具中，如F# web snippets，MonoDevelop等。（有人，请利用新的Apache许可证并为github编写插件， emacs和gvim :)，谢谢！）结果，大部分时间你都在查看代码，你将在环境/工具中进行，无论如何都可以按需显示类型。 / p>
其次，当缺少类型注释时，偶尔可能很难调试类型错误。当您得到一个奇怪的类型推断错误时，您无法弄清楚，添加一些显式注释来本地化类型错误会很有用。通常，您会在代码中看到一些愚蠢的错误，修复它，然后您可以删除不必要的注释。
当然，有许多地方需要类型注释，因为类型推断无法解决所有问题。有关详细信息，请参阅以下链接。你会在一段时间后习惯这些，并熟练地预测你何时或不需要注释。
http://lorgonblog.wordpress.com/2009/10/25/overview-of-type-inference-in-f/