defer not working correctly from loops

[emdete]

OS: linux, Devuan GNU/Linux 5 (daedalus/ceres)
Processor: 8 cpus, 64bit, little endian, Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
CC version: cc (Debian 11.3.0-3) 11.3.0

What did you do?

fn f(k int){
	eprintln(k)
}

fn main() {
	mut i := 0
	for i<10 {
		i++
		defer{f(i)}
	}
}

What did you expect to see?

output of 10 lines

What did you see instead?

only one line, the defer is executed once only.

this is the similar code in go:

package main
import "log"

func main() {
	i := 0
	for i<10{
		defer log.Printf("close %d", i)
		i += 1
	}
	log.Printf("done")
}

which works as expected.

[jrfondren]

"output of 10 lines" is obtained from more than one way to implement defer.

Consider:

# nim
proc main =
  for n in 1..3:
    defer: echo n
  echo "done"
main()

// d
void main() {
    import std.stdio;
    foreach (n; 1..4)
        scope(exit) writeln(n);
    writeln("done");
}

// zig
const print = @import("std").debug.print;

pub fn main() void {
    for ([_]i32{ 1, 2, 3 }) |n| {
        defer print("{}\n", .{n});
    }
    print("done\n", .{});
}

These all produce the following output:

1
2
3
done

These languages have this output as the deferred statement runs when the current scope is exited, which happens on each iteration of the loop, rather than when the function exits. Go, for completeness:

package main

import "fmt"

func main() {
	for i := 1; i <= 3; i++ {
		defer fmt.Println(i)
	}
	fmt.Println("done")
}

has this output:

done
3
2
1

Because there's this divergence in what defer does, and because v's docs don't use defer in a loop, I wasn't sure that v's version was buggy or an innovation:

fn main() {
	for i in [1, 2, 3] {
		defer { println(i) }
	}
	println('done')
}

output:

done
1

Reasons for it to be an innovation: it's very efficient to rewrite functions so that all the defer blocks happen on exit, rather than pushing closures to a stack like go. Reasons for it to be a bug: natural and less-trivial uses of defer won't work, like opening files in a loop while defering the close:

import os

fn main() {
	for name in ['file1', 'file2', 'file3'] {
		mut f := os.create(name) or { panic(err) }
		defer {
			println('closing ' + name)
			f.close()
		}

		// do some work
		f.writeln('just opened ' + name) or {}
	}
}

(this is an accidental case for deferring to the end of the loop like nim/d/zig. go wouldn't close any of these files until the end of the function, putting it at risk of hitting open file limits)

But having said all that, here's a big reason to think that the current v behavior is indeed buggy:

$ v run vfile.v
V panic: malloc_noscan(-89406639 <= 0)
v hash: 095f4bc
/tmp/v_1000/vfile.17441036274052130846.tmp.c:7411: at _v_panic: Backtrace
/tmp/v_1000/vfile.17441036274052130846.tmp.c:7647: by malloc_noscan
/tmp/v_1000/vfile.17441036274052130846.tmp.c:10740: by string__plus
/tmp/v_1000/vfile.17441036274052130846.tmp.c:17083: by main__main
/tmp/v_1000/vfile.17441036274052130846.tmp.c:17466: by main

that last example segfaults. If you remove the println() from the defer, it no longer segfaults, but it's still undesirable. Here's a working example:

import os

fn writes() {
	for name in ['file1', 'file2', 'file3'] {
		mut f := os.create(name) or { panic(err) }
		defer { f.close() }
		f.writeln('just opened ' + name) or {}
	}
}

fn main() {
	writes()
	for true {
		// do nothing
	}
}

Run that, and then look at its working directory:

-rw-r--r--  1 julian julian   18 Aug  5 05:16 file3
-rw-r--r--  1 julian julian    0 Aug  5 05:16 file2
-rw-r--r--  1 julian julian    0 Aug  5 05:16 file1

Only file3 was properly closed, causing the write to be flushed. file2 and file1 are empty files that, weren't leaked (?), but were closed inappropriately when writes() returned to main(), with the result that the write to them was lost.

[Wajinn]

This is related to a discussion topic (defer in for loop works unexpectedly). It appears the issue is a misunderstanding about or to haven't read about how defer works in V and that it's different from other languages.

A defer statement defers the execution of a block of statements until the surrounding function returns.

V's defer is called just before returning from the function and only when it does so normally. If the point is for V's defer to behave exactly like Go's defer, then it was suggested (by JalonSolov) to make that a feature request or bring it up for a vote. However, of the opinion that the present V way is correct (and to be built upon in the future), where defer is specifically the last thing done before returning.

Something I've noticed, is the V example from the OP does not closely follow the Go example, so might cause confusion. A closer example, to that of Go, is below. This shows println executing before defer, which is the last thing done.

import log

fn main() {
	log.use_stdout()
	mut i := 0
	for i < 10 {
		defer {log.info("count of ${i}")}
		i++
	}
	println("done")
}
/*
Output:
done
2025-03-01T17 [INFO ] count of 10
*/

[emdete]

i dont think that "running at end of scope" or "running at end of function" is related to the problem - its just anothertopic. point is: if i call defer n times, i expect my function is called n times regardless when. if v defines to run end of function (and its documented) that's fine. but nonetheless i need n runs.