> It's definitely expected that people will simply use pointers for these
types. Why do you find it useful to do otherwise?
I'm using the contents of big.Int, etc directly so that they act like
int64, etc and interoperate with them easily in a scripting language which
overloads operators. I've defined this hierarchy:
type Int = int64
type BigInt big.Int
type BigRat big.Rat
type Float = float64
type BigFloat big.Float
type Complex = complex128
type BigComplex struct{ Re, Im big.Float }
When big.Int passes into a function which accepts interface{}, I want the
big.Int contents copied so it's consistent with int64's behavior.
I thought maybe something had been overlooked when the big.Int, etc types
were designed. I'll just work with what's there.
On Sunday, December 10, 2017 at 7:49:07 PM UTC+13, Ian Lance Taylor wrote:
>
> On Sat, Dec 9, 2017 at 9:03 PM, <gavin...@gmail.com <javascript:>>
> wrote:
> >
> > In the "math/big" package, the Rat, Int, and Float types only have
> methods
> > that are attached to their pointer types, including the small handful of
> > them that don't modify the type's data, such as String() and Text().
> >
> > func (x *Rat) String() { ... }
> >
> >
> > Because I'm working with the contents directly instead of the pointers,
> this
> > means when I print them I don't get the nicely formatted results:
> >
> > fmt.Println(big.NewRat(23, 17)) // 23/17 -- what I want
> >
> >
> > fmt.Println(*big.NewRat(23, 17)) // {{false [23]} {false [17]}} -- what
> I
> > get
> >
> >
> > In order to get good formats, I've had to attach my own String() methods
> > after naming the types to something else:
> >
> > type BigRat big.Rat
> >
> > func (br BigRat) String() { ... }
> >
> >
> > This means I have to clutter my code with type conversions all over the
> > place, making it look messy.
> >
> > Should the String() method really have been defined in the Go std lib
> > directly on the Int, Rat, and Float types, instead of their pointer
> types?
> > If not, why not? Maybe I'm misusing those types' intended purpose,
> although
> > they work OK that way for me in all other respects.
> >
> > If so, will they be changed in the future, or would changing them break
> > existing code out there?
>
> It's definitely expected that people will simply use pointers for
> these types. Why do you find it useful to do otherwise?
>
> Ian
>
--
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.
