In Go, it’s a question of who owns the allocation. If you return a pointer type allocated within the function, the answer is “no one,” so the pointer escapes and has to be managed by the garbage collector.
replyIf the allocation is owned by the calling function which uses it internally and then doesn’t return it, it can be a stack variable. Or the same allocation can be reused many times in a loop. Or an array of allocations can be made all at once with foreknowledge of the total number.
If you pass a pointer into a function, the Go compiler can (and sometimes does) allocate it on the heap. Go has no allocation/ownership semantics, tragically, so the best we can do is depend on undefined behavior regarding the escape analyzer and hope the Go team doesn’t break it (which is a relatively safe assumption, considering that it’s unlikely that the Go team would start allocating things on the heap that were previously allocated on the stack—Go rarely regresses performance like this).
replyThe parameters named "out" here are not "output parameters" in the way you seem to be thinking. They are "input parameters" named "out", because they are the buffer or pipe you want the data written to.
reply`out` params in C# are params that must be set within the function. They are way to implement multiple return values and tell the caller "this is written to, not read from."
replyBut you might be conflating that with in/out for Contra/Co-variance when specifying a generic.
> They are way to implement multiple return values
replyThey are one way to implement multiple return values. For multiple returns, tuples can be used. In fact, async methods can’t declare out params
"in" and "out" are the names of the parameters, not qualifiers.
replyC# `out` is kinda nice because it can be `var`d and used directly.
replyErm... what do you mean?
reply if (int.TryParse(str, out var value) && value == 5)
{
// value is available
}
// value also available