See the section wrapped in """ in Jan's reply. Quoted differently:
> A parsing ambiguity arises when a composite literal using the TypeName
form of the LiteralType appears as an operand between the keyword and the
opening brace of the block of an "if", "for", or "switch" statement, and
the composite literal is not enclosed in parentheses, square brackets, or
curly braces. In this rare case, the opening brace of the literal is
erroneously parsed as the one introducing the block of statements. To
resolve the ambiguity, the composite literal must appear within parentheses.
>
> if x == (T{a,b,c}[i]) { … }
> if (x == T{a,b,c}[i]) { … }
On Tuesday, March 18, 2025 at 10:28:59 AM UTC-7 christoph...@gmail.com
wrote:
>
> I couldn't find a clear answer to my question. I didn't see what I was
> supposed to find in the reference manual.
> On my side I understood that the {} caused an ambiguity with the { of the
> if clause. The ambiguity is removed by putting the expression in
> parenthesis.
>
> if (v == Version{}) {. // <-- no more compiler error
>
> I suppose there would be a similar problem with an if statement. Didn't
> check.
>
> Le mardi 18 mars 2025 à 17:38:50 UTC+1, Davis Goodin a écrit :
>
>> Inline cost is part of how Go decides what funcs to inline. There are
>> some interesting patterns (maybe even idioms?) in Go that specifically try
>> to inline a lot of code to prevent values from escaping to the heap when
>> they don't have to. Concrete examples from -gcflags='-m -m':
>>
>> ./main.go:7:6: can inline fooCompositeLiteral with cost 3 as: func() { _
>> = Version{} }
>> ./main.go:11:6: can inline fooCompositeLiteralP with cost 4 as: func() {
>> _ = &Version{} }
>> ./main.go:15:6: can inline fooNew with cost 4 as: func() { _ =
>> *new(Version) }
>> ./main.go:19:6: can inline fooNewP with cost 3 as: func() { _ =
>> new(Version) }
>>
>> In a tight spot, that 1 cost might make a drastic difference.
>> On Monday, March 17, 2025 at 11:39:19 PM UTC-7 Dan Kortschak wrote:
>>
>>> On Mon, 2025-03-17 at 21:03 -0700, tapi...@gmail.com wrote:
>>> > I prefer *new(T) over T{}, because not only the reason here, but also
>>> > the former has a smaller inline cost.
>>>
>>> What do you mean by "inline cost"?
>>>
>>> https://godbolt.org/z/h8Krq7W8G
>>>
>>>
--
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+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/afc94dec-9a50-4cfb-8dd2-9e80c38e241bn%40googlegroups.com.
