Consider the following two functions:

func Foo(w *bytes.Buffer) {
arr := []byte("Hello, world")

func Bar(w io.Writer) {
arr := []byte("Hello, world")

In Foo, arr doesn't escape because the compiler can reason that
bytes.Buffer.Write does not leak arr. However, in Bar, arr does escape
because the compiler cannot reason what some generic implementation of
io.Writer.Write will do with arr. I find this unfortunately, especially
since there is a documented rule in io.Writer that "implementations must
not retain p", so it *should* be the case that arr never escapes.

I was thinking about this, but wouldn't the compiler be able to do a global
analysis of *all* concrete types that implement io.Writer. Suppose it was
able to determine that *none* of the implementers of io.Writer ever leak
the input argument, then it can then also reason that when the Write is
called in Bar, that arr also does not escape (since none of the
implementations of io.Writer that could possibly be used ever leak arr).

Going even further, suppose the compiler had the ability to track whether
inputs were mutated, then I can imagine a allocation-free version of the


This would work since the compiler can globally reason that none of the
implementations of io.Writer ever leak the input, and also that they never
mutate the input (assuming they obey the documented rule in io.Writer that
"Write must not modify the slice data, even temporarily"). This would avoid
the duplication of Write and WriteString methods that permeate the standard

Of course, I realize that there difficulties with implementing this:

    - What about recursive calls to Write? That is, if an implementation of
    Write calls io.Writer.Write under the hood (as is very common in wrappers
    like bufio.Writer), how does it determine that the implementation doesn't
    leak (when the analysis hasn't come to any conclusions about io.Writer yet)?
    - When components are iteratively compiled (package by package), what
    does the compiler output for a given package at the moment of compilation?
    It clearly doesn't have global knowledge of what types *could *end up
    implementing io.Writer and what their behavior would be like.

What are people's thoughts?


You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 3 | next ›
Discussion Overview
groupgolang-nuts @
postedFeb 12, '16 at 12:19a
activeFeb 12, '16 at 5:32a



site design / logo © 2021 Grokbase