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/366a95fa-9840-4f7b-becb-f94983b55fc0n%40googlegroups.com.
