Is the "new" function redundant?

[Nihlus]

Suppose we have a value-type S:
type S struct {x int; y int}
If we want to create a new object of this type we can write:
var s S; p := &s
and Go guarantees the validity of p as long as we use it (even if s is
a local variable inside a function and p is returned from the
function)
or we can write:
p := &S{x:1; y:2}
inititializing the new object while creating it.
So what is the point of "new" function? We cannot even use it to
initialize the created object. There is no formal separation between
stack values and heap values in Go so this function seems entirely
redundant. Why add it to the language definition then? It's presence
is probably misleading for people with C++ experience (like it was for
me).

An example program ilustrating all of the above:

package main
import ("fmt")

type S struct { x int; y int }

func main() {
var a [3]*S
for i,_ := range a {
a[i] = new(S); a[i].y = i
}
for _,p := range a { fmt.Printf("%#v ", p) }
fmt.Println()
for i,_ := range a {
var s S; s.x = i
a[i] = &s
}
for _,p := range a { fmt.Printf("%#v ", p) }
fmt.Println()
for i,_ := range a {
a[i] = &S{x:i,y:i}
}
for _,p := range a { fmt.Printf("%#v ", p) }

fmt.Println("\nbye...")
}

[Evan Shaw]

On Wed, Mar 2, 2011 at 8:10 AM, Nihlus <ho...@valentimex.com> wrote:
> So what is the point of "new" function? We cannot even use it to
> initialize the created object. There is no formal separation between
> stack values and heap values in Go so this function seems entirely
> redundant. Why add it to the language definition then? It's presence
> is probably misleading for people with C++ experience (like it was for
> me).

There's been lots of discussion about this already. This thread is
probably the best sample:

http://groups.google.com/group/golang-nuts/browse_frm/thread/9165d853de57374e

(The proposal in that thread wasn't adopted, by the way.)

- Evan

[Nihlus]

For me "make" clearly should be restricted to reference types only. I
find that the only justification for the existence of new if the lack
of user-defined function overloading. Given the mechanism var t T;
p := &t it would be trivial to define new when needed if it weren't
for the fact that users cannot overload function names. Thus it would
be necessary to write functions like "newT" rather than just "new"
for every type T. This raises a question of static methods but I will
start a separate thread for it.

On 1 Mar, 20:15, Evan Shaw <chicken...@gmail.com> wrote:

> On Wed, Mar 2, 2011 at 8:10 AM, Nihlus <h...@valentimex.com> wrote:
> > So what is the point of "new" function? We cannot even use it to
> > initialize the created object. There is no formal separation between
> > stack values and heap values in Go so this function seems entirely
> > redundant. Why add it to the language definition then? It's presence
> > is probably misleading for people with C++ experience (like it was for
> > me).
>
> There's been lots of discussion about this already. This thread is
> probably the best sample:
>

> http://groups.google.com/group/golang-nuts/browse_frm/thread/9165d853...

[Ostsol]

What's wrong with "NewT"? API-wise its purpose is just as obvious as
a T.New would be, and it's not as if it requires more typing to
implement.

-Daniel

[Steven]

On Tue, Mar 1, 2011 at 2:44 PM, Nihlus <ho...@valentimex.com> wrote:

For me "make" clearly should be restricted to reference types only.

And it only does. Actually, its more restrictive than that, since you can only use it with 3 of the 4 reference types. It works with slices, maps and chans, but not pointers. Hence the afore mentioned proposal. However, a lot of people have this stigma about pointers that prevents them from treating them like just a kind of type with certain properties.

 

I find that the only justification for the existence of new if the lack
of user-defined function overloading. Given the mechanism var t T;
p := &t it would be trivial to define new when needed

Are you really advocating removing a generic built-in function in favour of having to redefine the function for every type? 

if it weren't for the fact that users cannot overload function names. Thus it would be necessary to write functions like "newT"  rather than just "new" for every type T. This raises a question of static methods but I will start a separate thread for it.

 A common use for new is:

t := new(T).Init()