On Fri, Apr 05, 2024 at 03:01:44PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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
