There's an active proposal to add exactly what you're describing:

On the issue, adg comments the following about reasons why this isn't added:
There is some prior art. We actually implemented this (or something very
similar) in the lead-up to Go 1.

The spec changes:


The code changes:


There may be other changes that I'm missing. But in the end we abandoned
the changes (and reverted the spec changes); it tended to make the code
less readable on balance.
Personally, I would love to see more type inference, so we'll see whatever
happens to that proposal.

On Tuesday, January 12, 2016 at 11:03:30 AM UTC-8, Paul Borman wrote:

I was very happy when, several revisions ago, Go changed to infer
composite literal types in some situations. Sadly, it often seems to fall
short for me. For example ( http://play.golang.org/p/ZckskFKrZk ):

var s = []struct {
s1 []struct {
x int
s2 struct {
y int
s1: {
x: 42,
s2: {
y: 24,

Does not compile, I am forced to add []struct{x int} after s1: and struct{
y int } after s2: in order to compile. It seems it should be unnecessary
to specify the types in code like this as the type is not ambiguous. It
feels like it is no different from the the code asserting that the elements
in s are struct{s1[]struct{x int};s2 struct{y int}}. Is there a
compelling reason that the types can't be inferred in a situation like this?

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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 3 | next ›
Discussion Overview
groupgolang-nuts @
postedJan 12, '16 at 7:02p
activeJan 12, '16 at 7:28p

2 users in discussion

Paul Borman: 2 posts Thebrokentoaster: 1 post



site design / logo © 2021 Grokbase