Skip to content
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: Go 2: allow literal values without preceding literal types #24414

Closed
pcostanza opened this issue Mar 15, 2018 · 5 comments
Closed

proposal: Go 2: allow literal values without preceding literal types #24414

pcostanza opened this issue Mar 15, 2018 · 5 comments
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change
Milestone

Comments

@pcostanza
Copy link

In many cases, it is already clear from the context what type a literal value should be, so it would be convenient to allow for dropping the requirement to explicitly repeat the literal type. For example, in the following code, currently the literal type has to be repeated.

var v someStruct
v = someStruct{x: 1, y: 2, z: 3}

This proposal suggests that the last line could be written as follows:

v = {x: 1, y: 2, z: 3}

This in itself is not a major improvement for such simple cases. However, a particular use case I have in mind that this would enable is what in other languages is provided through keyword parameters. Here is an example to illustrate the use case:

func FormatFloat(f float64, opt struct {fmt byte; prec, bitSize int;}) string {
   fmt := byte(‘g’) // default value
   if opt.fmt != 0 {
      fmt = opt.fmt
   }
   prec := -1 // default value
   if opt.prec != 0 {
      prec = op.prec
   }
   bitSize = 64 // default value
   if opt.bitSize != 0 {
      bitSize = opt.bitSize
   }
   return strconv.FormatFloat(f, fmt, prec, bitSize)
}

In this example, checks against default 0 values are included to test whether a ‘keyword’ parameter was provided at the call site or not. This function can now be used as follows:

FormatFloat(3.14, {}) // use default options
FormatFloat(2.78, {fmt: ‘e’, bitSize: 32}) // deviate from some default options

Keyword parameters are very useful in other languages (IMHO), and dropping literal types from literal values if the context allows for it would add something very close without adding any extra features to the language.

@gopherbot gopherbot added this to the Proposal milestone Mar 15, 2018
@mvdan
Copy link
Member

mvdan commented Mar 15, 2018

This seems related to #21496. Though that is eliding types that are redundant within a single expression, such as nested struct types. Your proposal would go further, and infer context from an entire statement, as far as I understand.

@mvdan mvdan changed the title proposal: allow literal values without preceding literal types proposal: spec: allow literal values without preceding literal types Mar 15, 2018
@mvdan mvdan added LanguageChange Suggested changes to the Go language v2 An incompatible library change labels Mar 15, 2018
@pcostanza
Copy link
Author

@mvdan Indeed.

@ianlancetaylor ianlancetaylor changed the title proposal: spec: allow literal values without preceding literal types proposal: Go 2: allow literal values without preceding literal types Mar 15, 2018
@ianlancetaylor
Copy link
Contributor

This proposal needs to spell out precisely when types may be elided.

@jimmyfrasche
Copy link
Member

This appears to be a duplicate of #12854

@ALTree
Copy link
Member

ALTree commented Mar 15, 2018

Yes, this is a dup of #12854, there's even the same example for function calls

func Foo(args struct {
  A, B, C int
}) { ... }


Foo({A: 1, B: 2, C: 3})

closing here in favour of the old thread.

@ALTree ALTree closed this as completed Mar 15, 2018
@golang golang locked and limited conversation to collaborators Mar 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change
Projects
None yet
Development

No branches or pull requests

6 participants