range[a..b] semantics is a bit unclear to me

> Given > that seems that is how they are supposed to work. maybe, but "fixing" them by making them explicit would break practically all code out there - ie unfortunately, `Natural` is a `range` and it's used all over the pla

range[a..b] semantics is a bit unclear to me

> I think the best thing that can happen is that the range type is phased out > to be replaced with something more explicit. Given that seems that is how they are supposed to work.

range[a..b] semantics is a bit unclear to me

We don't use it as a matter of policy due to the implict / silent `Defect` raises that it introduces - ie proc function(v: range[0..10]) = echo v var x = 11 function(x) Run Another way to put it is that it's quite broken compared to other downsizing i

range[a..b] semantics is a bit unclear to me

Just briefly looking at these, most of them seem to be bugs in likely caused by `range` checks not being emitted inside implicit generic code. `proc stat0(n: static[range[0..5]]): string` seems to be caused by an issue with implicit conversions from literals to static ranges not being checked.

range[a..b] semantics is a bit unclear to me

I would like to use it more--I've seen it brought up as a killer feature--but I'm having some trouble understanding the borders of this little kingdom in Nim. Specifically I don't understand how/when/to what degree `range[a..b]` acts like a "real" type (like int8) and when it doesn't. I also do