Why is there a “new” keyword in Go?

[Florian Margaine]

Hi,

This question was posted here: http://programmers.stackexchange.com/questions/210399/why-is-there-a-new-keyword-in-go

I thought the best input would be from the Go devs so here goes in case you don't want to go read the question:

> I'm still puzzled as why we have new in Go.

> 

> `&Thing{}` is as clear and concise as `new(Thing)` to Go coders and it uses only constructs you often use elsewhere. It's also more extensible as you might change it to `&Thing{3}` or `&Thing{Feets:7}`.

> 

> In my opinion, having a supplementary keyword is costly, it makes the language more complex and adds to what you must know. And it might mask to newcomers what's behind instantiating a struct. It also makes one more reserved word.

> 

> So what's the reasoning behind new ? Is it something useful ? Should we use it ?

[Dave Cheney]

>> In my opinion, having a supplementary keyword is costly, it makes the
>> language more complex and adds to what you must know. And it might mask to
>> newcomers what's behind instantiating a struct. It also makes one more
>> reserved word.

[citation needed] Go has fewer keywords than any other curly brace
language, http://golang.org/ref/spec#Keywords.

>> So what's the reasoning behind new ? Is it something useful ? Should we
>> use it ?

You cannot do this without new

http://play.golang.org/p/-VfcIz8N2o

new isn't a headline feature of Go, you won't find it used often, but
when you need it, it is there.

Cheers

Dave

[chris dollin]

On 5 November 2013 11:29, Dave Cheney <da...@cheney.net> wrote:

>> In my opinion, having a supplementary keyword is costly, it makes the
>> language more complex and adds to what you must know. And it might mask to
>> newcomers what's behind instantiating a struct. It also makes one more
>> reserved word.

`new` isn't a reserved word in Go. It's a built-in function.

(Which means that you can use it as a name if you like -- the problem

 would be social rather than the compiler misliking your code.)
 

[citation needed] Go has fewer keywords than any other curly brace
language, http://golang.org/ref/spec#Keywords.

>> So what's the reasoning behind new ? Is it something useful ? Should we
>> use it ?

You cannot do this without new

http://play.golang.org/p/-VfcIz8N2o

 
Depends exactly what "this" means, but

  http://play.golang.org/p/xATp8B2jay

Chris

--
Chris "allusive" Dollin

[Job van der Zwan]

This might be a dumb question, but since we have the & operator to take the address of composite literals, why was that not extended to other types?

So, since we can do this:

http://play.golang.org/p/DtnXfT6uMM

Why not something like this:

http://play.golang.org/p/64wg6z2duZ

[Florian Margaine]

So basically, Dave's point doesn't really stand?

This kind of question is interesting, because Go wants to remain as minimal as possible from what I understand, yet there is this built-in function clobbering up the namespace.

Wasn't this discussed because it was just obvious that Go should have it because almost every language has it? Any decision around this kind of built-in stuff is quite important. And adding something for the sake of it is usually not a great idea since it's very hard to remove something.

Is Dave's (rare) case the only reason why `new` was added?

[chris dollin]

On 5 November 2013 13:41, Florian Margaine <flo...@margaine.com> wrote:

So basically, Dave's point doesn't really stand?

There are places where it's inconvenient to sneak in a new

variable just to take its address.

new(T) has an immediately straightforward meaning, rather than

being a multi-step idiom.

Dave's point only falls if mere technical possibility (of doing without
`new`) is compelling on its own. 

This kind of question is interesting, because Go wants to remain as minimal as possible from what I understand, yet there is this built-in function clobbering up the namespace.

Cluttering perhaps, but not clobbering.
 

Wasn't this discussed because it was just obvious that Go should have it because almost every language has it?

The "shall we keep `new`?" discussion pops up from time to time.

Since we can't take it out until Go 2, if I understand the Promise correctly,

there doesn't seem to be much to be had from going round the

loop again; by the time Go 2 is thinkaboutable, we might have some

different and better ideas ...

Chris

--
Chris "allusive" Dollin

[roger peppe]

I'm still a bit sad the Go team's proposal[1] to merge
new into make was grumbled about enough that
it didn't happen.

[1] https://groups.google.com/forum/#!msg/golang-nuts/kWXYU95XN04/iRfB7YEt57UJ

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Steven Blenkinsop]

I think the problem was that there had been a perennial argument about the decision to have make and new, since newcomers kept tripping on it. Said newcomers would then often have a "burn it with fire!" response, which in turn induced a defence of make/new as the One True Way by many members of the the community. By the time the proposal came up, the community had developed antibodies to the idea, and the resulting autoimmune response condemned the proposal to the dust bin.

[felix...@gmail.com]

never knew we can use 'new' that way, this nice

http://play.golang.org/p/-VfcIz8N2o

[roger peppe]

On 5 November 2013 17:40, Steven Blenkinsop <stev...@gmail.com> wrote:
> I think the problem was that there had been a perennial argument about the
> decision to have make and new, since newcomers kept tripping on it. Said
> newcomers would then often have a "burn it with fire!" response, which in
> turn induced a defence of make/new as the One True Way by many members of
> the the community. By the time the proposal came up, the community had
> developed antibodies to the idea, and the resulting autoimmune response
> condemned the proposal to the dust bin.

That's pretty much my interpretation of events too. Sad really.

[Kevin Gillette]

On Tuesday, November 5, 2013 5:01:40 AM UTC-7, Job van der Zwan wrote:

This might be a dumb question, but since we have the & operator to take the address of composite literals, why was that not extended to other types?

That'd be a syntactic ambiguity, since it could mean "address of the int variable", which you can define. The braces in the addressed composite literal syntax clarify that the identifier must specifically be a type.

 

On Tuesday, 5 November 2013 12:29:38 UTC+1, Dave Cheney wrote:

You cannot do this without new

http://play.golang.org/p/-VfcIz8N2o

http://play.golang.org/p/OZaT_3uKuG

[Dave Cheney]

I honestly don't understand why people get so hung up on the vestigial 'new'; there are much more trivial things to complain about, goto anyone? Or much more gotchaery ones like typed nils and variable shadowing. 

So, leave new alone, it's not hurting anyone and you really can live most of your life as a Go programmer with only a passing relationship to it.

--

[minux]

On Nov 5, 2013 1:58 PM, "Florian Margaine" <flo...@margaine.com> wrote:
>
> So basically, Dave's point doesn't really stand?
>
> This kind of question is interesting, because Go wants to remain as minimal as possible from what I understand, yet there is this built-in function clobbering up the namespace.

i wouldn't say it clobbers namespace because it's not a keyword. you can still use new as an identifier.

> Wasn't this discussed because it was just obvious that Go should have it because almost every language has it? Any decision around this kind of built-in stuff is quite important. And adding something for the sake of it is usually not a great idea since it's very hard to remove something.

you need to consider the history of the project. i think new is introduced first before there is make.

> Is Dave's (rare) case the only reason why `new` was added?

i don't think it is a rare case.

[Ian Lance Taylor]

On Tue, Nov 5, 2013 at 11:31 AM, minux <minu...@gmail.com> wrote:
>
> you need to consider the history of the project. i think new is introduced
> first before there is make.

That is true. In fact we struggled for a while before coming up with
the idea of make. If you look at the repository logs you can see that
make only shows up in January 2009, revision 9a924177598f.

The new builtin function also preceded the idea of &{} for taking the
address of a composite literal (and that syntax is in some sense
wrong; it probably ought to be (*T){fields of T} but there wasn't
enough reason to change it).

The new function is not strictly necessary but code does seem to use
it in practice. It's hard to get rid of it at this point.

Ian

[Kevin Gillette]

On Tuesday, November 5, 2013 12:29:23 PM UTC-7, Dave Cheney wrote:

Or much more gotchaery ones like typed nils. 

Is this referring to a boxed nil value producing a non-nil interface?

 

So, leave new alone, it's not hurting anyone and you really can live most of your life as a Go programmer with only a passing relationship to it.

Ironically, that's often the justification for rejection of a feature proposal in Go. 

[Steven Blenkinsop]

This is completely unnecessary, and an example of the knee-jerk reaction I'm talking about. Nobody was attacking you or Go. Everything is fine. Just having a friendly conversation on the internet.

[Florian Margaine]

And it was in fact just curiosity. I wouldn't ask if I didn't care :-)

[Dave Cheney]

Steven, Florian, you are correct. Please accept my apologies for my overreaction. 

[Florian Margaine]

This kind of reaction is awesome; thanks for being you.

Feelings set apart, I got my answer on this thread: `new` is originally there because it was the first, and and it's still the one to go for in some situations.

Thanks everyone for your input!

[harris...@gmail.com]

Replace new with makenew?