@Araq
1\. That is quite right, I did not. But as I recall, you always just tell me
that everything works just fine and back a year ago, when I found the first
bug, in distinct types and then in static[T], I had the feeling you would do
so. Sadly, I cannot say I am glad to be right here...
2\. It is quite reassuring that truth about you being aggressive and
over-optimistic (at the very least) feels abusive to you as it means there are
many people willing to help bright projects even when they encounter such
manners and bad treating. Makes me believe in mankind again.
3\. I already know that it is you who knows everything already (like
non-copying slices not being possible, because if you had failed to understand
or implement them clearly implies they are not possible at all), you really do
not have to constantly remind me that you have monopoly on that.
Anyway... I know we were talking about moving but I think moving from
discussion to crying is not the kind of moving we were supposed to discuss so
excuse me for stopping it here.
@Varriount
Yes, it is not. It works decently when combined with {call}, as mentioned by
mratsim, but for my use case it wasn't enough as I needed to move an existing
variable, not a routine call result. I tried a few solutions but none was
satisfying and some were not working at all. I didn't find any clue in the
manual and as the language author himself only answered with an equivalent of
"you're doing it wrong" (which, as far as I observed his previous posts, often
translates roughly to: "It's either impossible in Nim or I have no idea how to
implement it so just go home and go around the problem"), I guess it's not
generically doable without some kind of ugly magic I would prefer to avoid. Or
maybe I'm missing something.
I can't say it's that much surprising, actually. Nim is garbage-collected so as
a rule it doesn't follow single ownership and as a consequence, moving anything
other than a direct routine call result is, at least theoretically, unsafe. It
doesn't make it impossible but certainly not a natural thing to do (here I
implicitly admit that I use Nim's features in ways I don't think are considered
standard). It seems to me the reason for destructors being not-so-simple and
not-so-natural is pretty much the same thing: both moving and destructors need
deterministic lifetime. However, I do admit that if simplicity is one of the
main goals of the language, it's probably still a good choice, especially
considering Nim's GC's speed which is quite impressing. What puzzles me is why
these two approaches, single-ownership-by-default and
multiple-ownership-by-default, seem to mix. Of course they can be mixed in some
degree and I'm not sure what is the final goal (it seems to me that the goal is
changing, as I find the proposal of removing method multiple dispatch and
introducing concept vt-ptrs quite a big change) so I can't tell for sure, but
it seems to me that it's hardly possible to achieve all the goals (at least if
I'm right about what the goals are).
