[WIP] evalonce: let a {.evalonce.} = expr: side-effect safe, avoids copies

[timotheecour]

• should be able to replace sequtils.evalOnceAs with a nicer syntax
• this is almost always what you need inside templates when you want to avoid duplicate evaluation of arguments while avoiding copies
• likewise when you want to avoid duplicate evaluation of an expression yet still want to avoid copies
• builds upon new compiler feature introduced in new syntax for lvalue references: var b {.byaddr.} = expr #13508
• see unittests
• should help with crash on openarray interator with argument in stmtListExpr #13739

known limitation that could be lifted in future PR's

openArray inside non-symbol expressions
proc bar(s: openArray[int]) =
  template getS(): untyped =
    echo "side effect"
    s
  let a {.evalonce.} = expr

this limitation can be lifted in the future either by doing (recursive) code transformation

let a {.evalonce.} (body; ret)
=>
body
let a {.evalonce.} ret

or by making openArray 1st class

[Araq]

Can we see some borrow checking please? It shouldn't be too hard to do, the information a Nim program usually contains implies we're well prepared for it.

[Clyybber]

#13739 doesn't need this and should use the compilers ability to determine if its an lvalue or not by itself.
Since this is a smarter byaddr I suggest merging them.

[krux02]

In my opinion Nim already has too many features. I really don't want to add more features unless proven that we need them. So before new features are added:

• Please provide a precise specification what the new feature (in this case evalonce) does.

This is required to verify if this feature can really address all use cases.

• Please provide use case examples.

How would it help to write code more correct? How could it simplify code? I really like if you can prove that a specific feature would eleminate a big chunk branches. I did this in my PR here:
#13687. After all it implements a new feature (dollar on everything) and then also shows how many when compiles branches could be saved just because of that (ignoring the regressions aside and the other unrelated parts of the PR (yes the PR isn't after all it is still WIP).

• Then add tests. A lot of them.

Make sure this feature works well with other features of the language. Does it work well with lambdalifting? Does it work well with macros?

And last but not least, I don't like the name evalonce.

After all only if proven this feature is required it should be added.

• Test on all backends. Including Javascript and LLVM

[juancarlospaco]

Please change the name import pragmas, sounds confusing for users and searching the Doc.
Add static: tests since it should work at compile-time (?).

[Varriount]

I agree with @krux02 here. If I have code that needs to only evaluate an expression once, I use a variable assignment. If I have code that is hitting a bottleneck because of memory copying, I have the expression return a reference. If I can't do that, I explicitly use a pointer, not some hidden unsafe mechanism.

This code isn't memory safe, isn't thoroughly tested, and I'm not convinced it's needed enough to be included in the standard library. It's not even documented as being memory unsafe!

Nim shouldn't be C++ - we shouldn't need numerous damned hacks to achieve things that the compiler can figure out, or that can be done with common operations. Why don't we focus on making our existing features better/more thorough/more performant instead.

[Varriount]

@timotheecour How is this different from byaddr or shallowCopy? Could you provide some other examples/use-cases?

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.