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/f03566ce64bbf6bcf83adfb0c691b474c03402d0.camel%40kortschak.io.
