<p>I'm trying to understand a little convenience thing that I love about Go, and wish it existed more places. Take this piece of code:</p>
<pre><code>package main
type Foo struct {
Bar Bar
Bars []Bar
}
type Bar struct {
Val int
}
func main() {
Foo{
Bars: []Bar{
{
Val: 0,
},
},
Bar: Bar{
Val: 0,
},
}
}
</code></pre>
<p>If you'll notice the line below <code>[]Bar</code>, we're adding a struct without visually indicating it's struct type. Ie, we literally say:</p>
<pre><code> {
Val: 0,
},
</code></pre>
<p>Instead of:</p>
<pre><code> Bar{
Val: 0,
},
</code></pre>
<p>I absolutely love this feature. My question is, is it a bad idea if we went even further with this? What if when defining <code>Foo.Bar</code>, you didn't have to write <code>Foo.Bar = Bar{...}</code>, instead you could just write <code>Foo.Bar = {...}</code>. Again, omitting the struct type.</p>
<p>The example Bar code would look like:</p>
<pre><code> Foo{
Bar: {
Val: 0,
},
}
</code></pre>
<p>So why is this a bad idea? Sure, it visually obscures the type, but no more so than <code>[]Bar{ { Val: 0 } }</code> when used in large code bases. .. i.e., in <code>[]Bar{ {..} }</code> you can of course see the type of the inner struct, but less so when used in a large array.</p>
<p>Also, <code>Bar: Bar{..}</code> is quite an easy thing to write, in my experience it's often not so clean. Eg, <code>APIClient: someclient.SomeClient{..}</code>. Package names, longer describe type names, god forbid with Contexts, things just get.. long. Seeing as we already have type safety, as the field explicitly declares the type, do you think it's bad to use the same style of struct tags that <code>[]Bar{ {..} }</code> allows?</p>
<hr/>**评论：**<br/><br/>daydreamdrunk: <pre><p>This is <a href="https://github.com/golang/go/issues/21496" rel="nofollow">https://github.com/golang/go/issues/21496</a> ftr</p></pre>titpetric: <pre><p>Omitting struct field names and struct names is detrimental to how much you understand just by reading the code. You could set just <code>[]Bar { { 0 } }</code> and you realize that it tells you nothing aside from the enclosing struct. If reading code is important (and sometimes it is), you should definitely consider being more explicit/verbose in such cases. Depending on what you're doing however, there might be no need for it and you can omit just about everything - let's say if you are generating some code from external sources (like rainbow tables or something).</p></pre>throwlikepollock: <pre><blockquote>
<p>Omitting struct field names and struct names is detrimental to how much you understand just by reading the code</p>
</blockquote>
<p>As an aside, i thought that was idiomatic Go. I'm not at home, so i can't look up the docs - but at my old work they actually enforced not using the type. They considered it stutter typing, like <code>foo.NewFoo()</code> when <code>foo.New()</code> would suffice. <code>[]Bar { { 0 } }</code> is different than reducing stutter typing, since <code>Val</code> is of course not a stutter of the already displayed <code>Bar</code> type.</p></pre>jerf: <pre><p>In the case of <code>[]Bar { { 0 } }</code> you have a solid point.</p>
<p>It is less clear to me that the cost/benefit tradeoff comes out in favor of writing the types down when you've got <code>[]Bar{ {0}, {4}, {3}, {88}, {23}, {-1}, ...}</code> etc.</p>
<p>Though this mostly bites me only during table-based testing. Some elision is allowed but I find myself wishing for a bit more then.</p>
<p>(Also, if I meant to say "cost/benefits clearly favor not having to spell out the type", I would have. I am truly conflicted between the convenience of the read vs. the write here.)</p></pre>
