let
x = [0, 1, 2]
a = len([0, 1, 2]) # ok
b = len @[0, 1, 2] # ok
c = len x # ok
d = len [0, 1, 2] # fails
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).
len [1, 2,3] is a bit unfortunate, it's even worse for tuple foo (1, 2) vs foo(1, 2) but it's a price I'm willing to pay if I can make nice macros and DSL like:
forZip x in a, y in b, z in c:
echo (x + y) * z