Hi all, still a nim-noob but I enjoy writing code in Nim. Nim is great and I
use it both for non-os and os environments.
Please don't purge the range-types; they are super useful and every serious
language should have it.
In my eyes the dead-code elimination feature within Nim is unneccesary;
You should put the problem you are describing in the title.
This discussion is pointless and triggers too much attention. `sizeof(float)`
won't change. if you want 32 bit float use float32.
I haven't been on the forum for quite a while, just the chat and I would also
like to put my wishlist of things to remove here.
* the range type. Well just use `type range[low,high: static[int]] = distinct
int` No need for this to be a language feature
* arrays with a size that is not an
Patching the stdlib to use concepts where it makes sense instead of `openArray`
is also a fine idea. It's really used a lot -- (`algorithms`, `strutils`,
`sequtils`, `random`, `stats`, etc.). `Iterable` & `Indexable` concepts make
sense to me as a decomposition for all those interface
`openarray` as a concept was raised here:
[https://github.com/nim-lang/Nim/issues/6528](https://github.com/nim-lang/Nim/issues/6528)
but in light of the discussion for memRanges/slices/pointer+len/span that
happened here:
> *
>
> Default Not Nil (and cleaning up the associated initialization that springs
> from this). Newbies always get caught with a seq that hasn't been
> initialised. If you want nil, be explicit about it.
The better solution for today's Nim is to remove `nil` from seqs. Internally
`@[]` can be
> has the idea of openArray being a concept been considered? It seems to make
> sense - an array has a set of properties that concept describes well:
> indexable, len, etc
Certainly, but I want to keep `openArray` and turn into borrowed array slices.
The borrowing aspect is hard to achieve
Well it's time we talk about what v1 should be about. In my opinion v1 should
be today's Nim with features that don't work well put behind the
`{.experimental.}` switch or removed altogether. Oh and of course we should
remove the already deprecated stuff. But the goal should be to keep much of
Opencollective is also an option. (Got issues with Bounty Source too)
Default `Not Nil` (and cleaning up the associated initialization that springs
from this).
Newbies always get caught with a seq that hasn't been initialised.
If you want `nil`, be explicit about it.
While excess can be bad, and there are inconsistencies that should be repaired,
I think a "batteries included" stdlib is a good thing. E.g., the recent
`enumerate` for loop macro in `tests/macros/tforloop_macro1.nim` should
probably be in `lib/pure/sugar.nim`. I think the duplication (`re` and
12 matches
Mail list logo
