Re: [RFC][PATCH] t-prio-queue: simplify using compound literals

From: Jeff King <peff@peff.net>
Date: Apr 7, 2024, 01:28 UTC
Message-ID: <20240407012844.GC1085004@coredump.intra.peff.net>
In-Reply-To: <xmqqedbjtqnr.fsf@gitster.g>

On Fri, Apr 05, 2024 at 03:01:44PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > Yeah, this seems pretty reasonable. I think we've traditionally been
> > hesitant to pass or return structs by value, but that's mostly
> > superstition.
> 
> We should still be hesitant against the practice to the same degree
> that we are hesitant against struct assignment, especially when the
> struct is of nontrivial size, or the struct has a pointer member
> whose memory ownership semantics goes against shallow copying of the
> struct.

Good point. There are really two thresholds: is this something that should be totally forbidden, and is this something that is generally a good idea. I think the answers here are "no" and "yes" respectively.

It is an OK solution for "plain old data" types like date_mode that are essentially just marshalling arguments, but not for more object-oriented code that might have ownership over pointers.

> In this particular case, I do not know offhand if .strftime_fmt is
> safe to be shallowly copied, but I trust you two know and/or have
> already looked at the implications.

René already went through each caller, but yeah, I think it is fine here. This whole thing is just a convenience over having callers pass around a separated (enum, strftime_fmt, local) triple.

-Peff