I replied to a blog post by Tosos over here:
The reply was long enough that I thought it warranted posting here too. I expand on why “var” is not dangerous and can go away. I also describe why it isn’t duck or dynamic or anything but strong and static. If you know F# this is nothing new to you.
Here it is:
I love these.
@Mike Borozdin:
Consider F#’s definition of methods(functions). It is just as strongly typed as C#, yet the compiler is left to infer the return type.In the example above the return type is not weak, it is not vague or dynamic or relying on duck typing. The return type is the anonymous type defined by the select clause of the linq statement. All of the static type checking and strength of warnings and errors of the compiler will still occur.
I’d like to see similar syntax, but drop the var, it is needless noise.
e.g.
public GetFirstPageOfFiles(string dir)
{
return Directory.GetFiles(dir).Take(10);
}The signature of the method GetFiles takes a string and returns a string so we (and the compiler) KNOWS that GetFirstPageOfFiles returns a string.
But have we simplified the language as much as we can? F# wouldn’t make me specify the type of the argument to the method. It would infer it.
public GetFirstPageOfFiles(dir)
{
return Directory.GetFiles(dir).Take(10);
}Again, the argument to GetFiles is string so the compiler knows how to turn the method signature of
public GetFirstPageOfFiles(dir)
into
public string GetFirstPageOfFiles(string dir)
Where the compiler can’t infer, it should give an error and require the explicit use of the type.
This exactly the behavior of var now.
As for #3, I would NOT want this to be the default behavior. The default behavior should be strong-static types. As strong and as static as possible. That said, some compiler support for the equivalent of duct typing via reflection would be rather nice. AFAIK what you are asking for is already available through a 3rd party library from David Meyer at http://www.deftflux.net/blog/page/Duck-Typing-Project.aspx
With respect to default behavior being duck, Phil Haack is wrong, everyone is wrong. If you want that, use Iron Ruby or Iron Python.
I wrote about my uncertainty about the GetEnumerator duck here: http://jrwren.wrenfam.com/blog/2007/07/21/c-has-duck-typing/ It may have been necessary. If it wasn’t necessary, I’d call it a mistake. Maybe it was an accident. I don’t know.
Could I be more against duck typing? Yes, I could be against it entirely. I could completely misunderstand it. Unfortunately I’ve written in duck languages. I’ve probably written more code in PHP, Python and Perl than I have in C#. (I wrote A LOT of Perl and PHP.)
My simply request is to require the manual selection of behavior of duck, like Boo. Yes, I say “like boo” a lot, but much could be learned from boo. Boo had extension methods before C#. Boo has duck in a strong, static typed language. Of course, boo is not a special case. It is best to learn as much as possible from neighbors so that you can make your own decisions about things. My request is probably going to be granted. Charlie Calvert wrote about the dynamic keyword and dynamic blocks as a possible solution to this.
