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). 

Reply via email to