> If the `threadpool` library were to switch to using `Isolated[T]`, would that > mean that they no longer need to be in core as the "computer magic" parts > required are already encapsulated there?
Yeah, pretty much. > Is `isolation` considered to be a main stream library that can be used to > update standard libraries or is it just experimental even though it isn't > marked as such? It's a building block, builtin, standard, whatever you want to call it. > As a documentation issue, shouldn't the `isolated` library be added to the > Standard Library main documentation page as it as already been added to the > Searchable Index? If so, I can do that for you. Please do so. > Again, this should be corrected? Yes. > I think it should be, or at least everything except maybe parallel should be, > as I would like to see basic multi-threading in Nim be as easy as using "go > routines" in GoLang, which isn't quite there even using Isolated[T]: ... I don't care about direct comparisons with Golang as Golang requires runtime data race checking. Copying bad design is not good design. > although a re-written `FlowVar[T]` could take care of the isolation itself, > but again, maybe that's "compiler magic" and would mean that `FlowVar[T]` > would need to be core, right? Or is it possible to return a `ResultVar[sink > Isolated[T]]` without "compiler magic" with some library tweaking? I'm not sure I understand the question. The plan is to have more light-weight channels that are based on Isolated[T]. We don't need FlowVar[T] anymore but it might make sense to distinguish between a "send-only" channel view and a recv-only channel view via Nim's type system. > Guess I had better file an issue on that? The bug is that the compiler doesn't prevent `ptr Channel[sink Isolated[string]]` which is not a valid type, `sink` is a type modifier that can only be applied to parameters directly. > As to `parallel`, do you see any way of stabilizing it and getting it off of > the experimental list, at least for use with `--gc:arc/orc`, for version 2.0? No. `parallel` is a nice idea but hasn't seen enough testing. I also have not yet figured out how to map it to GPU programming which was one of my goals. And as you said yourself, maybe its use cases are too narrow so that the complexity of a "disjoint checker" doesn't pay off.
