In example1, the // BAD: y escapes is there because y should not escape
from that function, but the current algorithm needs to be improved for this
case. In that closure, the address of y is captured as the closure argument
p and since p is only dereferenced, the analysis should not consider it to
escape.
In example3, the analysis above applies and y should not escape. y is
closed over and dereferenced, but we correctly do not mark it as escaping.
In example2, y contains no pointers; it can never escape. The test was to
see if capturing/closing over a non-pointer value would cause it to escape.
It's a bit confusing, but to restate, in example1, y should not escape even
though it currently does.
On Mon, Oct 3, 2016 at 11:09 PM, 刘桂祥 <liuguixiang...@gmail.com> wrote:
> // example1.go
>
> package main
>
>
> func main() {
> var y int // BAD: y escapes
> func(p *int, x int) {
> *p = x
> }(&y, 42)
> }
>
> example1.go y escape to the heap
>
> // example2.go
>
> package main
>
> func main() {
> var y int
> func(x int) {
> y = x
> }(42)
> }
>
> example2.go y is not escaped and why ??
>
> // example3.go
>
> package main
>
> func main() {
> a := 100
> y := &a
> func(x int) {
> *y = x
> }(42)
> }
>
> example3.go y is not escaped and why ??
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
