For common types such as string and seq it's difficult to obtain information about how to perform common operations like appending data or slicing.
Wading through the behemoth that is the system is tough, especially for a newbie.
I propose the following:
system/seq.htmlsystem/string.htmlsystem/set.htmlThe simplest way to implement this might be to split up the system module into separate files and include them all in system.nim, then add these separate files into the doc gen.
I think doing so will make it much easier to get started with Nim as system holds some really fundamental aspects of the stdlib and the language.
I'd rather split system.nim. For all purposes.
I would prefer that option, didn't think you'd go for it though.
In any case, what I suggest could be the first step towards that goal :) Looks like this should go into the v1 milestone ;)
Funny I always thought you are against it @dom96
@Araq
btw: i have a POC that helps doing that based on {.nosystem.} that also avoids include hacks and instead uses import
Although include is very useful in certain niche scenarios, in the vast majority of cases import should be used as leads to much saner modular code (and avoids pitfalls specific to include eg {.exportc.} procs, top-level doc in include bugs, or compiler re-parsing the same file etc).
Currently, {.include.} is IMO being overly abused and {.nosystem.} pragma along with splitting up system will greatly help with that aspect (in addition to other aspects)
Progress so far:
I would say this is enough for 0.20 (it is labeled for 0.20 milestone) and this can be closed.
Q: Why not move more things out?
A: It's not as simple as it might seem. Trust me, I'm the one who worked on moving iterators, assertions, etc.
Most helpful comment
I'd rather split system.nim. For all purposes.