Thanks Ian and Dan for your returns.
I'm pretty agree with Dan considering that if append can understand that an
empty slice provides nothing to add, I think min/max should be able to
understand that an empty slice provides nothing to compare to the first
param. Moreover, today, it is possible to write "max(5)" exactly like with
an empty slice...
What is the more confusing for me is that it seems that the "unpacking"
operator is not evaluated before func call, but during func call (and
blocked). I suppose that's linked to an optimization/performence reason but
it's working fine with every func which take a variadiac param (like
append but every custom func too): except min/max...
Le lundi 20 janvier 2025 à 20:35:40 UTC+1, Dan Kortschak a écrit :
> On Mon, 2025-01-20 at 10:42 -0800, Ian Lance Taylor wrote:
> > Calling append with an empty slice is well defined. Calling min or
> > max with an empty slice is not.
>
> If the only input to min/max were the slice, this would be true, but I
> do not think it is in the case that is implemented in the standard
> library where the signatures are fn(T, ...T), e.g. s := []int{};
> max(42, s...) is 42.
>
>
--
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/b7f5ff28-c68a-4157-93d2-063a783d57d7n%40googlegroups.com.
