Nim v2: what would you change?

I especially agree with Yardanico, Zoom and kobi. * Refactor the compiler, pull out docgen, remove legacy flags, etc. * Default `not nil` \- this eliminates `Option`'s speed vs correctness [conundrum](https://github.com/nim-lang/Nim/pull/18401). * Finish view types and other half-done featu

Nim v2: what would you change?

As relatively new language for me, i have some early feedback for the breaking stuff: * Includes and imports started to kick my ass early on, especially when you have emit of c and c++. Stuff is non visible to other modules and you end up including everything to make stuff work. * Lot of go

Nim v2: what would you change?

When we're at object variants, it would be great if they could automatically declare the type for the discriminator, like sum types in other languages.

Tetronimia: a version of *that* game for your terminal

Tetronimia is back with the new release **v0.3.0** : * ✨ Add support for configurable key mapping (fixes [#7](https://github.com/indiscipline/tetronimia/issues/7)) via the `--kbd` option, which takes a user-provided mapping or o

Why macros does not provice CommentStmt node in TypeDef ?

I need to access doc comments to autogenerate API docs for a web framework. In macros, I can access CommentStmt that are in procs , but not in type section. I dont know if i missed something. Does anyone know a way to extract doc comments from object declaration ? import macros

Nim v2: what would you change?

Allowing to re-declare the same field in different object variant cases would be neat! I'm not sure why it is forbidden given that it's impossible for the two fields to be defined at the same time (different label). What I mean is something like type ObjKind = enum

Nim v2: what would you change?

* I personally like the options module, and suggest making it part of prelude, and then make types not nil by default. * the flow sensitive typing is a good feature, i hope it passes the experimental stage. * I ran into issues with methods, they work but not always, there are some corner c

Nim v2: what would you change?

it's my little problem to do management. Decimal with fixed lengths initialization of variables when they are declared thong with fixed lengths As for the rest, although I make nim my No. 1 language, I haven't ingested everything? so ... and if nim had its own GUI it wouldn't be a bad thing

Nim v2: what would you change?

I think this problem will be alleviated with better tooling, if nimsuggest was able to automatically add an import if you autocomplete from a module you haven’t imported yet.

Nim v2: what would you change?

Please consider making circular dependent types possible. I have largely abandoned Nim as my primary language because I always run into the same problem when my projects grow larger than a handful of files: I need to put all my types into a single type block in a single file. This simple does n

Nim v2: what would you change?

@detla \- How about `import foo {.used.}` the way it works for variables? Then things like `include std/prelude` could just use that. I realize that in concert with my `import bar {.style: asCamel.}` [RFC suggestion](https://github.com/nim-lang/RFCs/issues/456#issuecomment-1114171802) that "imp

Nim v2: what would you change?

> Enable circular dependencies to overcome complexity barrier (I don't want to > redesign existing C/C++ projects to make my idea compile) Both module instantiation and object instantiation do not allow for circular dependencies because an abstraction layer is missing.

Nim v2: what would you change?

A more powerful memory profiler if make sense! to help the developer to find cyclic data-structure and dump it's contents more easier when --mm:arc is enable. IMO memory manager are more important than other things.

Nim v2: what would you change?

> Well we have overloadable Enums so that's less of an issue you just do Opt1 > and use it as such, no longer need to be worried about a prefix. The issue is more about use with autocomplete and discover ability. Just using `Opt1` compiles but you have to either remember all the options or look

Nim v2: what would you change?

As a Nim noob, I`m worried by the import policy. Without a bunch of imports (like sequtils, strutils, strformat), I can't do much at all. When I start a new project and insert all these imports that had turned out to be necessary last time, I get warnings about unused imports – so I remove them,

Nim v2: what would you change?

Enable circular dependencies to overcome complexity barrier (I don't want to redesign existing C/C++ projects to make my idea compile) Better tools (finding out why vscode extension is not working is always a guess game). Solve the anti-virus problem in windows from this side (I had to stop usi

Nim v2: what would you change?

One way is to support user-defined ``()`` operator for `typedesc`.

Nim v2: what would you change?

I would prefer instead of `new`/`init` or C++ like constructors, or default fields for objects, there was a way to overload `T()` object construction.

Nim v2: what would you change?

> That's something that can always happen without breakage. Let's focus on > language/stdlib changes that need breakage :) The problem is that it won't happen _ever_ if not someone who knows the compiler actually does it... It may not be a backward-breaking change, but it certainly is a **back-

Nim v2: what would you change?

IMO, 2.0 should be a big cleanup first. I assume the codebase has collected a lot of tech debt, a lot of stuff to be deprecated. Since 2.0 can be backward incompatible, those should be removed and the foundation can be improved for big new features. Existing features that are halfbaked should be

Nim v2: what would you change?

The "lazy symbols" RFC allows this but it's not listed in the roadmap. Probably because it was thought that it would get immediately implemented, so it's likely 2.0 will get this.