The future of `sharedlist` and `sharedtables`

[konsumlamm]

The sharedlist and sharedtables modules have a number of issues:

• bad documentation (not even every proc has a doc comment)
• doesn't work with GC (I assume that applies to both, only the documentation for sharedtables actually says that, I'm also not sure how it works with ORC)
• unstable API
• few routines (especially sharedlist)
• judging from https://gist.github.com/GULPF/6d49e74af9992f8fc65476a9264488a0 and https://github.com/nim-lang/RFCs/issues/398#issuecomment-891762652, they are rarely used

So I think we should do something about it! There are a few possibilities for their future that I see (feel free to propose more):

1. keep everything as-is (I hope we can agree that this is not a good idea)
2. deprecate the modules and move them to their own nimble package
3. deprecate the modules and let others write a nimble package for shared data structures (that will hopefully be better)
4. keep the modules in std and fix the above issues (or at least some of them)

I have no particularly strong opinion on which option would be best, but my personal preference is option 3, since I think that the modules are too specialized for std and I don't see them being actively maintained.

[Araq]

Deprecate them and eventually provide better things in nim-lang/threading or elsewhere but nim-lang/threading is a natural place to put it.

[juancarlospaco]

Deprecate.