New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: spec: allow &5 to allocate and initialize int 5 #19966

Closed
lavalamp opened this Issue Apr 13, 2017 · 10 comments

Comments

Projects
None yet
10 participants
@lavalamp
Copy link

lavalamp commented Apr 13, 2017

Use case: Many structs intended for json or other serialization use pointers to tell the difference between fields that have been set vs not set. It's currently awkward to declare instances of such structs. An example:

type Settings struct {
  Foo *int
  Bar *string
}

Today one generally does:

func intPtr(i int) *int { return &i }
func strPtr(s string) *string { return &s }

mySettings := Settings{
  Foo: intPtr(5),
  Bar: strPtr("baz"),
}

The proposal would be a language change to just allow:

mySettings := Settings{
  Foo: &5,
  Bar: &"baz",
}

Filing an issue to have a place to discuss (none of my searches turned up a similar feature request).

@ahmetb

This comment has been minimized.

Copy link

ahmetb commented Apr 13, 2017

From my personal experience, I use helper functions such as ToIntPtr ToStringPtr to accomplish referencing/unreferencing pointers specifically for JSON etc. serialization use case in the fields: https://godoc.org/github.com/Azure/go-autorest/autorest/to If it goes through a function, you can take address of it and return.

@bradfitz bradfitz changed the title language idea: allow taking address of literals proposal: language idea: allow taking address of literals Apr 13, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

bradfitz commented Apr 13, 2017

Note that all language changes are on hold until any Go2, so this will likely be low priority during future proposal reviews.

@gopherbot gopherbot added this to the Proposal milestone Apr 13, 2017

@gopherbot gopherbot added the Proposal label Apr 13, 2017

@griesemer

This comment has been minimized.

Copy link
Contributor

griesemer commented Apr 13, 2017

If I recall correctly we had actually discussed this possibility back in the early days when we (@rsc in particular) designed the details of addressability. Note that even for composite literals, the use of & as in &T{...} is an exception.

@lavalamp

This comment has been minimized.

Copy link

lavalamp commented Apr 13, 2017

Yeah I definitely wasn't expecting this to get taken up for go 1.9 or even at all.

A common mistake this would prevent is:

i := 5
myStruct := Settings{
  A: &i,
  B: &i,
}

// Then later someone else mutates myStruct.A and B also changes!

I think this issue differs from the old email thread (which I hadn't found, thanks) in that there's an actual use case :)

@rsc rsc changed the title proposal: language idea: allow taking address of literals proposal: spec: allow &5 to allocate and initialize int 5 Jun 16, 2017

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Jun 16, 2017

See also #9097.

@dsnet

This comment has been minimized.

Copy link
Member

dsnet commented Jul 18, 2017

Related to #7054. The pattern for struct fields with *T for builtin types typically descends from the desire to distinguish between the zero-value and an unset value.

@jba

This comment has been minimized.

Copy link

jba commented Aug 28, 2017

Just an observation: if there were read-only types, then &5 could have type readonly *int, and then it wouldn't require an allocation.

@leighmcculloch

This comment has been minimized.

Copy link
Contributor

leighmcculloch commented Sep 29, 2017

This is another a pattern I've seen to deal with this inline which isn't great:

myStruct := Settings{
  A: func(i int) *int { return &i }(5),
  B: func(i int) *int { return &i }(5),
}

@bradfitz: I'm lacking some understanding on what causes this to be a language change. Does the language change label indicate it wouldn't be backwards compatible, or that it more generally makes a change to the langauge spec?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Sep 29, 2017

The LanguageChange label is applied to all proposed changes to the language, whether backward compatible or not.

At this stage we are very unlikely to make any meaningful change to the language before Go 2.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Jan 3, 2018

Closing as dup of #9097. #9097 is the same idea, but seems slightly more flexible in that it permits specifying the type. (Perhaps this approach is intended to permit the type also, but in any case it seems like a dup.)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.