Oh I see what you mean now.
Should max(slice...) be allowed (ie. just the slice and no unary value) ?
It would behave like slices.Max() I think. Maybe there is deep reason for
not allowing but it would be nice to have for sure.
On Monday, 20 January 2025 at 15:21:10 UTC Benoît Marguerie wrote:
> Hi Stephen,
> max(5,slice) has no sense by itself, I'm agree with you.
>
> But the issue is about max(5,*slice...*) which should accept the
> "unpacking" operation like the append function. I know there's a buildin
> type "Type" for append while the min/max functions use the Generic with the
> interface cmp.Ordered but from an "usage point of view", it doesn't seem
> "understandable".
>
> Le lundi 20 janvier 2025 à 16:14:54 UTC+1, Stephen Illingworth a écrit :
>
>> What value do you think should be returned for "max(5, slice)" ?
>>
>> On Monday, 20 January 2025 at 15:00:04 UTC Benoît Marguerie wrote:
>>
>>> Hi,
>>>
>>> Even if the spec precises :
>>> > slice arguments are not permitted
>>>
>>> I wonder if there's any real technical reason to prohibit the use of the
>>> slice variadics during *min/max* buildin functions, when it's allowed
>>> with *append* (which creates inconsistent behavior between buildin
>>> functions)?
>>>
>>> Example:
>>> ```
>>> func main() {
>>> slice := []int{0, 1, 2, 3, 4, 5, 6, 7}
>>> padding := []int{8, 9}
>>>
>>> slice = append(slice, padding...)
>>> forbidden := max(5, slice...) //Doesn't build due to this line....
>>>
>>> fmt.Println(forbidden)
>>> }
>>> ```
>>> -> https://go.dev/play/p/pWzf9WKgW3q
>>>
>>>
--
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/dcb5292c-7640-4339-80b7-4c37dfce88d1n%40googlegroups.com.
