proposal: Go 2: Remove 'new' function

[themeeman]

This has been thought about before in the community but no one has mentioned it here before.

The new function returns a pointer to the zero value of the type passed into it. For structs, this can be replaced with the syntax &MyStruct{}, which has exactly the same result.

For maps and slices, the same syntax can be used. Additionally, it is rarer that you will need a pointer to a map or slice than a struct.

For all the other types, new can potentially be used if you want to obtain a concrete pointer to them; however, this use-case seems so narrow that it raises the question of the point of having new at all.

Currently, every instance of the new function in the standard library can be trivially replaced with the literal syntax. It is used in some test files, but these could be replaced with maybe two lines of code.

So, it seems that the only uses of new is for aesthetic reasons, which for me doesn't justify its existence at all. Removing it makes the language easier to learn as it removes the chance of confusion from someone coming from an OOP background.

[networkimprov]

Altho Go2 won't be strictly backwards-compatible, the principals have said recently that they don't want to break existing code by removing features (see links). That would appear to preclude changes like this.
#21291 (comment)
#21291 (comment)

[mvdan]

This has been proposed before - for example, see #20446.

[DeedleFake]

I always thought it would make sense to combine new() and make() such that in the same way make(map[string]string) creates a new, non-nil map[string]string, make(*string) would create a new, non-nil *string. As @networkimprov said, though, they're trying to reduce the amount of backwards incompatability from Go 1 to Go 2 as much as possible, and this seems like something that's too small to bother removing.

[Azareal]

new() and &MyStruct{} are not the same thing.
One requires you to set at-least one internal field and the other not.

[deanveloper]

One of the things I love about C that I can't do in C++ and other OOP languages is the ability to name a variable new. While I can (I think?) name a variable the same as a built-in function, it'd be very bad practice.

I won't lie, I'm almost in favor of this almost entirely so I can name a variable new without feeling bad, haha

[deanveloper]

@Azareal https://play.golang.org/p/8bPZmdqdKoj ?

[ianlancetaylor]

This is also related to #9097.

We aren't going to get rid of new without some alternative expression for cases like new(int) that currently can not be written as an expression in any other way.

We're fairly unlikely to get rid of new in any case, since it would break existing code for what seems to be a fairly small benefit.

Closing in favor of #9097 and friends.

[Azareal]

@Azareal https://play.golang.org/p/8bPZmdqdKoj ?

That's odd, I remember the compiler complaining when I tried to do that before, maybe it changed.