code review 5301056: big: usable zero Rat values without need for explicit i...

big: usable zero Rat values without need for explicit initialization

- no explicit API change, but new(big.Rat) now creates a big.Rat value
  of 0 that is immediately usable, in sync. w/ the conventions elsewhere
- various cleanups along the way

[gri, 2011-10-20 23:24:53]

Hello rogpeppe@gmail.com (cc: golang-dev@googlegroups.com),

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

[gri, 2011-10-21 20:56:09]

Hello r@golang.org (cc: golang-dev@googlegroups.com),

Please take another look.

[r, 2011-10-21 21:07:38]

LGTM

[gri, 2011-10-21 21:11:39]

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

big: usable zero Rat values without need for explicit initialization

- no explicit API change, but new(big.Rat) now creates a big.Rat value
  of 0 that is immediately usable, in sync. w/ the conventions elsewhere
- various cleanups along the way

R=r
CC=golang-dev
http://codereview.appspot.com/5301056

[rog, 2011-10-24 10:48:35]

[sorry for slow response - i've been abroad since wednesday]

LGTM, except that i think that nat{} should be written as nat(nil)
throughout, which will save an unnecessary allocation each time, AFAICS.

On 21 October 2011 01:24,  <gri@golang.org> wrote:
> Reviewers: rog,
>
> Message:
> Hello rogpeppe@gmail.com (cc: golang-dev@googlegroups.com),
>
> I'd like you to review this change to
> https://go.googlecode.com/hg/
>
>
> Description:
> big: (make) zero Rat values usable w/o initialization
>
> - various cleanups along the way
> - includes pending CL 5312044
>
> Please review this at http://codereview.appspot.com/5301056/
>
> Affected files:
>  M src/pkg/big/int.go
>  M src/pkg/big/int_test.go
>  M src/pkg/big/nat.go
>  M src/pkg/big/nat_test.go
>  M src/pkg/big/rat.go
>  M src/pkg/big/rat_test.go
>
>
>

[rog, 2011-10-24 12:09:32]

On 24 October 2011 12:48, roger peppe <rogpeppe@gmail.com> wrote:
> LGTM, except that i think that nat{} should be written as nat(nil)
> throughout, which will save an unnecessary allocation each time, AFAICS.

actually it occurs to me that an easy compiler optimisation would be to
use the same data pointer when making all zero-length slices,
thus avoiding the need for nat{} to do an allocation.

i can't off-hand think of anything this would break, as slices
aren't comparable, and there's no element to take the address of.
(Printf("%p") is one place non-unsafe code can observe it, but
i don't see that's necessarily a problem).