code review 5345055: FAQ: update

FAQ: update

[r, 2011-11-08 22:20:52]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg/

[bradfitz, 2011-11-08 22:32:44]

http://codereview.appspot.com/5345055/diff/1/doc/go_faq.html
File doc/go_faq.html (right):

http://codereview.appspot.com/5345055/diff/1/doc/go_faq.html#newcode983
doc/go_faq.html:983: rudimentary, however.
this paragraph paints a bleaker picture than my understanding of the situation.

It's not super naive: it does have smarts annotating functions, for instance. 
Isn't that used to detect escapes when calling between different functions?

[r2, 2011-11-08 22:33:48]

On Nov 8, 2011, at 2:32 PM, bradfitz@golang.org wrote:

> 
> http://codereview.appspot.com/5345055/diff/1/doc/go_faq.html
> File doc/go_faq.html (right):
> 
> http://codereview.appspot.com/5345055/diff/1/doc/go_faq.html#newcode983
> doc/go_faq.html:983: rudimentary, however.
> this paragraph paints a bleaker picture than my understanding of the
> situation.
> 
> It's not super naive: it does have smarts annotating functions, for
> instance.  Isn't that used to detect escapes when calling between
> different functions?

i didn't say super naive, i said rudimentary. i think that's fair.

what would you say instead?

-rob

[dsymonds, 2011-11-08 22:38:57]

Java doesn't count as a member of the C family? It has pass-by-reference
semantics sometimes.

[eds2, 2011-11-08 22:43:32]

http://codereview.appspot.com/5345055/diff/1/doc/go_faq.html
File doc/go_faq.html (right):

http://codereview.appspot.com/5345055/diff/1/doc/go_faq.html#newcode1243
doc/go_faq.html:1243: stacks, supported by recent modfications to its linker.
s/modfications/modifications/

[rsc, 2011-11-08 22:44:15]

LGTM once everyone else is happy

http://codereview.appspot.com/5345055/diff/1/doc/go_faq.html
File doc/go_faq.html (right):

http://codereview.appspot.com/5345055/diff/1/doc/go_faq.html#newcode983
doc/go_faq.html:983: rudimentary, however.
The hard part about this paragraph is the tone of the
original text, which is still there.  I'd replace this paragraph with:

In the current compilers, if a variable has its address taken, that variable
is a candidate for allocation on the heap.  However, a basic <em>escape 
analysis</em> recognizes common cases when such variables will not
live past the return from the function and, in those cases, avoids the
allocation.

[r2, 2011-11-08 22:47:50]

On Nov 8, 2011, at 2:38 PM, David Symonds wrote:

> Java doesn't count as a member of the C family? It has pass-by-reference
semantics sometimes.
> 

well, kinda sorta. receivers are pointers that look like values, but otherwise
what do you mean? i think function args (the subject of that section) are always
pass-by-value.

-rob

[r2, 2011-11-08 23:15:18]

On Nov 8, 2011, at 2:38 PM, David Symonds wrote:

> Java doesn't count as a member of the C family? It has pass-by-reference
semantics sometimes.
> 
I just checked the book. All parameters to methods are "pass-by-value".

-rob

[dsymonds, 2011-11-08 23:25:51]

On Wed, Nov 9, 2011 at 10:15 AM, Rob 'Commander' Pike <r@google.com> wrote:

> On Nov 8, 2011, at 2:38 PM, David Symonds wrote:
>
> Java doesn't count as a member of the C family? It has pass-by-reference
> semantics sometimes.
>
> I just checked the book. All parameters to methods are "pass-by-value".

I guess in that sense, yeah. It's the same as how
chan/map/slice/func/interface are "reference" values, so what you've
got is fine.

[dsymonds, 2011-11-08 23:36:30]

LGTM

[r, 2011-11-09 00:26:06]

*** Submitted as http://code.google.com/p/go/source/detail?r=a67f688c043e ***

FAQ: update

R=bradfitz, r, dsymonds, edsrzf, rsc
CC=golang-dev
http://codereview.appspot.com/5345055