Hacker News

How does the dead code elimination work when using args to Printf? If static strings are fed into an empty function, I can imagine it does nothing. However, this I have less of a firm grip upon

  dlg.Printf("the thing.Something is %+v", thing.Something())

since surely golang will still call Something, and still call Printf

And don't misunderstand me: it's a grave pet peeve of mine to do action inside the args to Printf but I can tell you it's a very common [anti-]pattern so I'd presume your users will want a story for how that interacts with the "disappears completely" claim

0xFEE1DEAD 3 days ago [ - ]

In short: You're right - Go will still evaluate argument expressions. In hindsight, I should've made that more obvious, not calling this out initially was an expert blind spot on my part, not an intent to mislead.

If we consider this example:

  func risky() error {
    return fmt.Errorf("unexpected error")
  }

  func risky2() error{
    return fmt.Errorf("also an error")
  }

  func main() {
    fmt.Printf("something failed: %v", risky())
    dlg.Printf("something failed: %v", risky2())
  }

And look at the disassembly:

  0x10009f354  d503201f  NOOP                ; Dead code of dlg.Printf
  0x10009f358  b0000000  ADRP 4096(PC), R0   ; Load "also an error" string address
  0x10009f35c  9124ec00  ADD $2363, R0, R0   ; Calculate exact string address
  0x10009f360  d28001a1  MOVD $13, R1        ; Set string length=13 (R1)
  0x10009f364  aa1f03e2  MOVD ZR, R2         ; Clear R2
  0x10009f368  aa1f03e3  MOVD ZR, R3         ; Clear R3
  0x10009f36c  aa0303e4  MOVD R3, R4         ; Clear R4
  0x10009f370  97ffd890  CALL fmt.Errorf(SB) ; Call fmt.Errorf

What disappears is the logging work (formatting, interface/slice plumbing, I/O) and the call itself. Go cannot eliminate calls to functions inside of Printf because they could produce side-effects. Eliminating functions calls like this would be very expensive to do and would clashes with Go's focus on fast compilation times.

I'll add a section to the README that explains this. Thanks for pointing it out.

llimllib 3 days ago [ - ]

It's easy to show that you're right and that code isn't dead so it can't be eliminated:

    package main
    
    import (
     "fmt"
    
     "github.com/vvvvv/dlg"
    )
    
    func risky() error {
     _, err := fmt.Printf("unexpected error\n")
     return err
    }
    
    func main() {
     dlg.Printf("something failed: %s", risky())
     risky()
    }

prints "unexpected error" twice

2 days ago [ - ]

[deleted]

exasperaited 3 days ago [ - ]

This is a thing I had a little "are you sure?" itch in my brain about, but you've expressed so clearly in four lines of comment, and this is me showing gratitude for the comment and the untangling of my brain.

ETA: Presumably if there was at least an option for passing a closure that would provide a way to address this? Since the closure will only uselessly compile, and not actually uselessly run?

0xFEE1DEAD 2 days ago [ - ]

I've added a section to the README that goes into the subtleties of compiletime elimination and what to watch out for to ensure that calls to dlg.Printf can actually be eliminated: https://github.com/vvvvv/dlg?tab=readme-ov-file#true-zero-co...

I'd appreciate any feedback on whether these changes make the behavior more transparent and less misleading.