As always the Nim Manual is a treasure trove. I just discovered this move optimization

With the {call} constraint you can have 2 procs, one if there are multiple references and one if the compiler knows the reference is unique !

proc `[]=`*(t: var Table, key: string, val: string) =
  ## puts a (key, value)-pair into `t`. The semantics of string require
  ## a copy here:
  let idx = findInsertionPosition(key)
  t[idx].key = key
  t[idx].val = val

proc `[]=`*(t: var Table, key: string{call}, val: string{call}) =
  ## puts a (key, value)-pair into `t`. Optimized version that knows that
  ## the strings are unique and thus don't need to be copied:
  let idx = findInsertionPosition(key)
  shallowCopy t[idx].key, key
  shallowCopy t[idx].val, val

var t: Table
# overloading resolution ensures that the optimized []= is called here:
t[f()] = g()

2017-09-08 08:05:03

Nim's "implicit const reference" is a bit similar to C++'s "implicit return move", I guess. While Nim's one is nice (I miss you, Ada...), it can be a bit misleading as there seems to be no natural way to get mutable argument with no var (i.e. move it, not mut-ref a variable external to the routine).

I consider Nim's "moving" at least a bit unreliable. Maybe my luck to find random compiler bugs is infinite but I've already encountered many segfaults thanks to shallowCopy not working properly. I guess it isn't that surprising, I use Nim for all kinds of weird things (with lots of meta-magic).

By the way: nice to see a fellow Rustacean here.

2017-09-08 11:00:29
shallowCopy does work properly, it's just that you don't understand it.
2017-09-08 12:51:04

@Araq I'm sorry to hear you don't know your own language's only compiler's problems as well as a person who doesn't even use this language as her primary one. ^^" Or maybe it's the manual which can't describe all the tiny details (which would be a bit surprising as it even describes things that did not make it into compiler yet).

By the way: I don't think being harsh for people will bring you larger community. ^^" Especially posts suggesting everything's trivial (depends on a person AND problem, I'd say), one-liner (that's obviously false) and any weakness of the language is weakness of one's mind (yeah, still remembering out little chat about slicing ).

2017-09-08 19:49:58

Hmm, shallowCopy is not move right?

IMO, using ptr would be better for fine-grained manual memory management.

2017-09-12 04:04:46
Copying semantics in Nim are fairly straightforward:
  • Object types, sequences, and strings copy on assignment
  • References do not copy on assignment

shallowCopy and shallow sidestep the fact that strings and sequences copy on assignment. If you use these procedures, any affected variables (which in the case of shallowCopy means both arguments) must not be modified.

Udiknedormin: shallow and shallowCopy should not be considered equivalent to C++ move operations. If they are used as such, data corruption will result.

2017-09-12 17:37:55

@Araq I'm sorry to hear you don't know your own language's only compiler's problems as well as a person who doesn't even use this language as her primary one. ^^" Or maybe it's the manual which can't describe all the tiny details (which would be a bit surprising as it even describes things that did not make it into compiler yet).

By the way: I don't think being harsh for people will bring you larger community. ^^" Especially posts suggesting everything's trivial (depends on a person AND problem, I'd say), one-liner (that's obviously false) and any weakness of the language is weakness of one's mind (yeah, still remembering out little chat about slicing ).

  1. You haven't reported any bugs. (No, vage ramblings on this forum do not count as bug reports!)
  2. Your reply is much more abusive than mine. In fact, I might delete your impertinences later.
  3. You already know everything already ('"import foo" is always a design mistake'), making discussions with you futile.
2017-09-12 18:27:15

@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).

By the way, it's a bit funny that I encountered an issue with single-ownership when writing some code for nimpylib which mocks python, a typical shared-ownership-by-default language. ^^" I didn't expect that.

@Araq

Please forgive me the sarcastic-serious mix in this reply. I was trying to organize it by topic so the style is not that consistent. Before reading, consider the fact that if I was just to be mean to you, I would be too lazy to write such an essay. ^^" So here is my reply:

1. That is quite right, I did not. But as I recall, you always just tell me (and some other people doing weird things) that everything works just fine. Back a year ago, when I found the first bug, in distinct types and then in static[T], I had the feeling, based on the comments on others' problems, you would do so. Sadly, I cannot say I am glad to be right in this case...

By the way: it is not like I am always sure something cannot be done. I always hope it is easily doable and it is just me who forgot about something. More than that: sometimes I think something should be easily doable when writing code for reply and then it turns out something does not work the way it seems supposed to work. It happens in many (I think all) languages, it is just I encounter it more often when writing Nim code. I also encountered some writing, say, C++, Fortran or Rust but most of the times I just found the answers (or a bug report) already there so no need to write it.

You said you read my comments but at the same time you call them ramblings and nowhere-near-bug-reports. If you really read them, I take it you also read the code samples I attach sometimes (which, in my opinion, could be often almost copy-pasted as bug reports). Yet you do not comment why these samples (or my assumptions) are wrong. Why is it so?

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.

If you like it that way, go ahead and delete my comments (or any other comments), it is your language/forum/whatsoever anyway, why even bother mentioning it? Not like it would confirm my claim of you being closed for any comments other than "thank you for this amazing language". Which are a bit funny as well... isn't using the language a thanks itself?. I had quite a lot of fun with it myself but the more I love a language, the more I criticize it (just like I used to criticize Ada or Scala before I found a new lovelang). So I guess you should actually be happy that I criticize your language this much as it implies it means quite a lot to me. ^^"

I commented on how you treated me as I was having many issues with many languages and the top-users (not to mention authors) were always helpful, which I considered one of the greatest advantages of communities. And it was so even for languages with much better manuals and docs than Nim. I think you will admit that this is not Nim's greatest advantage (and it does not have to be). Even if we are here for fun, nobody likes to hear just how stupid they are instead of an answer to the actual problem they encountered.

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; or maybe you just don't like the idea, which is perfectly ok, but then why not just say so), you really do not have to constantly remind me that you have monopoly on that.

Apropos import foo: I guess I will not find it now but I am pretty sure you yourself encountered users to use from foo import ... often (it seems to me that you even said import foo was an unlucky choice but I am not sure on that), so I was pretty sure you would agree on that. Also, I did not just say that I think so, I gave an example (there are many more). So I do not think summing the comment up as me just being cocky is fair enough. Also, there are many topics (I think most of the threads on this forum) I would not comment on as I do not know much in this topic.

Anyway... I know we were talking about moving but I think moving from discussion to garbage-storm (because by "you just don't get it" you ended a discussion with ad-personam and now it is just me trying to persuade you I am not your enemy) is not the kind of moving we were supposed to discuss so please excuse me for stopping it here. You can send me an e-mail if you really want to continue.

2017-09-12 21:24:00
<<<••123••>>>