Back to the roots of v2.. and what it could be

> In fact, the whole thing can stay in the same git repo, as long as each part > gets versioned separately (and therefore can be released independently: > important fixes don't have to wait for a nim release and vice versa) It never occured to me that we can do it this way. Requires some thoroug

Back to the roots of v2.. and what it could be

> Somewhere along the way, people started associating the celebration of > ORC/ARC with the idea that we should piggyback lots of other breaking changes > on top Well, that's because ARC/ORC were released rather long ago and "celebration" can't happen if the standard library is not utilizing th

Back to the roots of v2.. and what it could be

Agreed with treeform on these: > * Make Orc the default gc. > * Threads on by default (including new isolate/channels/threading). > * Get many of the experimental features stable: overloadable enums, the dot > "." macro, default object values... > * Make -d:ssl as default, fix bugs around

Back to the roots of v2.. and what it could be

I would edit, but it doesn't work: When splitting up the std lib, this doe **not** mean that they need to be handed off to a different set of maintainers or have lower quality standards applied! In fact, the whole thing can stay in the same git repo, as long as each part gets versioned separat

Back to the roots of v2.. and what it could be

My wish list for v2 of Nim is simple: * Make Orc the default gc. * Threads on by default (including new isolate/channels/threading). * Get many of the experimental features stable: overloadable enums, the dot "." macro, default object values... * Make -d:ssl as default, fix bugs around SS

Back to the roots of v2.. and what it could be

Recently, the idea has formed that we should release a V2 that systemically breaks things "while we're at it", since a v2 was announce anyway. Originally, the v2 discussions started as an idea to celebrate ORC/ARC and the switch to a new GC - this will bring many changes to how canonical Nim cod

Nim producing void as template argument instead of the type

`'0` means return type of the proc; in this case `Bar[K, V]`. That's why it's safe to use for a constructor because C++ constructor will always be named after their own type. So doing - even if it's less intuitive - will work for every constructor. proc makeBar*[K, V]() : Bar[K, V]

Learning threads

Can anyone tell me what am I missing here? I'm trying to learn about nim types and threads. I made this small example and theoretically it should work. The output is: Thread started! Input: 1 Handling command... Result sent back. Thread stopped! Run Th

Nim producing void as template argument instead of the type

Thanks @Clonk! proc cmakeBar*[K, V](k: typedesc[K], v: typedesc[V]) : Bar[K, V] {.importcpp: "Bar<'*1, '*2>()", constructor, cdecl.} Run Does not look bad! will use it for now. It would be great to know if there is support in the syntax though. I was trying to lo

Nim producing void as template argument instead of the type

The following works : # Bar.h #include template class Bar { public: Bar() { std::cout << "Bar " << std::endl; } void doWithBar() { std::cout << "doWithBar " << std::endl; } ~Bar() {}

any way to extra version info from .nimble file?

You can use pkginfo 👌 A small utility package that can collect all the .nimble meta data and package dependencies on compile-time. It can be used to get meta data from all kind of dependencies (direct/indirect). All the information is stored in a `pkginfo.j

Nim producing void as template argument instead of the type

Not sure if I should create another question for this, let me know if that's the case. Im struggling with this signature: proc makeTMap*[K, V]() : TMap[K, V] {.importcpp: "TMap<'*0, '*?>()", constructor .} Run What should be used there instead of the "?" Thanks