Mirror of forum.nim-lang.org

6803 :: About sink and copy: is this expected behavior?

• wt (orginal) [2020-09-11T12:10:52+02:00] view original

  type
    A = object
      val: int
    
    B = object
      val: A
  
  proc `=sink`*(dest: var A, source: A) =
    echo "sink A"
    dest.val = source.val
  
  proc `=`*(dest: var A, source: A) =
    echo "copy A"
    `=destroy`(dest)
    dest.val = source.val
  
  proc dupB(b: var B) =
    var b2 = b
  
  proc main() =
    var b: B
    dupB(b)
  
  main()
  Run

  When I run the above program, it outputs nothing. Is this expected behavior of compiler?

  I am a little confused. Of course, the following program runs as expected:

  type
    A = object
      val: int
    
    B = object
      val: A
  
  proc `=sink`*(dest: var A, source: A) =
    echo "sink A"
    dest.val = source.val
  
  proc `=`*(dest: var A, source: A) =
    echo "copy A"
    `=destroy`(dest)
    dest.val = source.val
  
  proc `=sink`*(dest: var B, source: B) =
    echo "sink B"
    dest.val = source.val
  
  proc `=`*(dest: var B, source: B) =
    echo "copy B"
    `=destroy`(dest)
    dest.val = source.val
  
  proc dupB(b: var B) =
    var b2 = b
  
  proc main() =
    var b: B
    dupB(b)
  
  main()
  
  
  Run

  It outputs:

  
  copy B
  copy
  Run

---

• snej (orginal) [2020-09-12T01:18:54+02:00] view original

  My non-expert opinion: Your first program is a no-op. Copying a B and then letting the copy go out of scope does nothing. It's possible the compiler completely optimized this away. Have you tried a program that does something with the copied value?

---

• gemath (orginal) [2020-09-12T13:14:24+02:00] view original

  Another non-expert here: The doc says

  The = hook is called for assignments that couldn't be transformed into =sink operations.

  Could that be the case (or even falsely assumed by the compiler) here?

---

• Araq (orginal) [2020-09-13T08:57:15+02:00] view original

  The generic thing is probably a bug, please report it on github. The other problems are not problems, Nim is allowed to optimize away moves as well as copies. See the section "Cursor inference / copy elision" of the spec. This goes way beyond what C++ does.

---

• wt (orginal) [2020-09-14T10:44:57+02:00] view original

  I saw this in the Nim Destructors and Move Semantics :

  proc `=sink`*[T](a: var myseq[T]; b: myseq[T]) =
    # move assignment, optional.
    # Compiler is using `=destroy` and `copyMem` when not provided
    `=destroy`(a)
    a.len = b.len
    a.cap = b.cap
    a.data = b.data
  Run

  So, =destroy and copyMem will be the default behavior.

  I am sorry about the generic example, which was a clerical error. var b: B[int] should be var b: B[A], and that outputs a correct result.

---

• shirleyquirk (orginal) [2020-09-14T15:01:23+02:00] view original

  I don't believe this is an incorrect output, on the contrary: the fact that there's nothing output in the devel compiler should be celebrated as the consequence of all the hard optimization work going on

  you can force b2 to be actually copied from b rather than having that copy elided by initializing it to a value before the copy

  proc dupB[T](b: var B[T]) =
    var b2 = B[T]()
    b2 = b
  Run

---

• wt (orginal) [2020-09-15T08:21:30+02:00] view original

  Adds =sink and = for B[T], there's still nothing in the output when using the devel-latest compiler (1.3.5).

  type
    A = object
      val: int
    
    B[T] = object
      val: T
  
  proc `=sink`*(dest: var A, source: A) =
    echo "sink A"
    dest.val = source.val
  
  proc `=`*(dest: var A, source: A) =
    echo "copy A"
    `=destroy`(dest)
    dest.val = source.val
  
  proc `=sink`*[T](dest: var B[T], source: B[T]) =
    echo "sink B"
    dest.val = source.val
  
  proc `=`*[T](dest: var B[T], source: B[T]) =
    echo "copy B"
    `=destroy`(dest)
    dest.val = source.val
  
  proc dupB[T](b: var B[T]) =
    var b2 = b
  
  proc main() =
    var b: B[A]
    dupB(b)
  
  main()
  Run

---