Should true or false terminate callback iteration?

In some languages it's necessary or cleaner to do iteration by providing a callback function that receives items and returns a boolean that indicates whether to continue or stop the iteration.

Which is the preferred value to indicate desire to stop/continue? Why? What precedents exist?

Example in Go:

func IntSliceEach(sl []int, cb func(i int) (more bool)) (all bool) {
    for _, i := range sl {
        if !cb(i) {
            return false
        }
    }
    return true
}

> Which is the preferred value to indicate desire to stop/continue?

true for continue

> Why?

Example 1:

func example(i interface{}) {
    if w, ok := i.(io.Writer); ok {
        // do something with your writer, ok indicates that you can continue
    }
}

Example 2:

var sum int = 0
it := NewIntStatefulIterator(int_data)
for it.Next() {
    sum += it.Value()
}

In both cases true (ok) indicates that you should continue. So I assume that it would be way to go in your example.

Foreword: The following answer applies to a callback function which decides based on the current item(s) whether the loop should terminate early - this is what you asked.

This is not to be confused with a function that progresses and reports if there are more elements to process, where a true return value is generally accepted to signal that there are more elements (for which a good example is Scanner.Scan()), and whose typical use is:

scanner := bufio.NewScanner(input)
for scanner.Scan() {
    // Process current item (line):
    line := scanner.Text()
    fmt.Println(line) // Do something with line
}

Sticking to bool return type

Usually returning true to indicate termination results in code that is easier to read. This is due to the nature of for: if you do nothing, for continues, so you have to explicitly break if you want to terminate early, so having a clean termination condition is more common.

But it's a matter of taste. You may go whichever you like, but what's important is to name your callback function in a meaningful way that will clearly state what its return value means, and thus looking at the code (the condition in which it is used) will be easily understandable.

For example the following names are good and the return value is unambiguous:

// A return value of true means to terminate
func isLast(item Type) bool
func terminateAfter(item Type) bool
func abort(item Type) bool

// A return value of true means to continue (not to terminate)
func keepGoing(item Type) bool
func carryOn(item Type) bool
func processMore(item Type) bool

Using these results in easily understandable code:

for i, v := range vals {
    doSomeWork()
    if terminateAfter(v) {
        break // or return
    }
}

for i, v := range vals {
    doSomeWork()
    if !keepGoing(v) {
        break // or return
    }
}

// Or an alternative to the last one (subjective which is easier to read):

for i, v := range vals {
    doSomeWork()
    if keepGoing(v) {
        continue
    }
    break
}

As negative examples, the following callback function names are bad as you can't guess what their return value mean:

// Bad: you can't tell what return value of true means just by its name:
func test(item Type) bool
func check(item Type) bool

Having error return type

It's also common for the callback to not just test but also do some work with the passed item. In these cases it is meaningful to return an error instead of a bool. Doing so, obviously the nil return value indicates success (and to continue), and a non-nil value indicates error and that processing should stop.

func process(item Type) error

for i, v := range vals {
    if err := process(v); err != nil {
        // Handle error and terminate
        break
    }
}

Having enum-like return value

Also if multiple return values have meaning, you may choose to define constants for return values, which you can name meaningfully.

type Action int
const (
    ActionContinue Action = iota
    ActionTerminate
    ActionSkip
)

func actionToTake(item Type) Action

for i, v := range vals {
    switch actionToTake(v) {
    case ActionSkip:
        continue
    case ActionTerminate:
        return
    }
    doSomeWork()
}