Also note the conceptual difference:
`for x in someIterable: foo(x)` deals with the _elements_ of someIterable, e.g.
with the letters of a string.
`for i in 0 ..> something.len: foo(i)` is conceptionally quite different albeit
well known from most older languages and deals with the _indices_.
It is now
for u in i ..< words.len:
Run
So no space between .. and <. The old notation with space could give wrong
results in rare cases due to operator priority.
Apologies if this has been asked before, I am new here.
I started learning Nim yesterday, and read through the
[tutorial|[https://nim-lang.org/docs/tut1.html]](https://nim-lang.org/docs/tut1.html\]),
where it says:
> > Zero-indexed counting have two shortcuts ..< and ..^ to simplify counting
>
Yes, I agree that this function is not generally what is needed. Most of the
time, we want a string and "format" is what should be used. I didn’t wanted to
discuss the decision, I was just curious to know if there exists situations
where it actually gives a wrong result.
Now, in my case, this i
We decided that this variant of round is almost never what you should use. The
stdlib needs to avoid procs that trick you into programming bugs. If you
**really** need it, use this code:
proc myRound*[T: float32|float64](x: T, places: int): T=
if places == 0:
result =
Hello all,
When compiling (with development version of Nim) a module which uses the
"round" function from the "math" module, more precisely the "round" function
with two arguments (the second one being the number of positions after decimal
point), I got a deprecation warning. The recommended wa
