<div dir="ltr"><div>Mike - that's technically possible to implement but I don't see the cost/benefit stacking up that well - I think any new syntactic constructs come with a non-neglible implementation/documentation/user attention cost that can quickly accumulate if we're not selective about what we put into the language (see C++).  Tangentially, that particular syntax is difficult to parse unambiguously - you could be trying to index a variable called int and pass it into max.  <br><br></div><div>The problem I see with #3 is that we're allowing overloaded functions so that the standard library seems slightly neater/more friendly.  If that results in a bunch of exceptions where users can't do something that "ought to" work - composing two standard library functions reduce/max, I just don't see enough of a net benefit (if any) to the programmer experience to justify the implementation burden.  <br><br>This of course is somewhat subjective - I tend to like languages where there is a simple and consistent but powerful set of core rules that are orthogonal and compose well together - you can learn the basic rules and don't have to worry about many exceptions.  Other language designs will special-case common constructs so that use-cases that the language designer expects to be common will be shorter or "cuter", or add features that don't compose well with other features and come with caveats/exceptions.  I think C, Haskell and Python are examples of the former, and Perl, R and C++ are examples of the latter.  I'm not sure which camp we see ourselves in.<br><br></div><div>I haven't found complete documentation on Apple Swift's type inference, but it doesn't seem like it does anything very sophisticated - Swift/T already does similar local type inference.<br><br></div><div>- Tim<br></div></div>