cblake, tim_st et al Yes. I never liked Nims easy going in some points like the one that shows its ugly head here. Simple reason: ambiguity - as in "not _evidently and strikingly_ clear" \- is known to be one of the major infectors in software, comparable to rats in a city.
My personal rule, i.e. the way I handle it, ignoring some of Nims "generosity", is: a proc call has the form **foo(...)** \- always with only one exception: UFC with only one arg. `[1,2,3].len` is OK, but `len [1,2,3]` is not in _my_ personal rule book. I _do_ understand why Araq calls it "fixed" (rather than "allowing for ambiguity"): there is no var `len`, hence it must be a proc call. But what do we gain? Saving two parentheses - but for a price, namely confusion. I know, I know, I'm quite picky and somewhat like Cassandra but decades of software development - and bugs! - should have tought us the lesson that readability should always trump saving-a-key-stroke. This world doesn't need more "cool" "everything goes" languages; it needs languages that allow for the creation of _safe_ code (incl. maintainability ~ readability!) in as comfortable a way as possible. Which Nim to a large degree - and way more and better than anyone else - gladly does deliver indeed - modulo some well meant hiccups (like this one).