ok. Thanks Ian and Dan for your explanations even if I understand that the reason is just an implementation reason which introduces a bias on unpacking operator (seperation of concern would have be great here I suppose but maybe less efficient).
Le lundi 20 janvier 2025 à 23:54:43 UTC+1, Dan Kortschak a écrit : > Agreed. My understanding was that this was because the min and max > functions get written as an unrolled set of cmp instructions, rather > than as a loop, and while this was not included in the spec for obvious > reasons, it is why the spec was written that way. > > Dan > > On Mon, 2025-01-20 at 14:35 -0800, Ian Lance Taylor wrote: > > > > I would say that this is because the language doesn't provide a way > > to > > write what the spec says. The spec says "The built-in functions min > > and max compute the smallest—or largest, respectively—value of a > > fixed > > number of arguments of ordered types. There must be at least one > > argument." The language doesn't support writing that function > > declaration. That is, the declaration is not really fn(T, ...T). It's > > fn(T, T, T, ...) where there must be at least one value. > > > > We could change the definition of min/max to permit writing max(42, > > s...). But today the spec does not permit that. And to me the change > > doesn't seem worth making. We already have slices.Min and slices.Max. > > > > Ian > > > > -- 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/98721516-29f1-4c13-8e88-36bbb342da8dn%40googlegroups.com.
