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,
On Mon, Jan 20, 2025 at 11:35 AM 'Dan Kortschak' via golang-nuts
wrote:
>
> 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 wo
Go 1.24 introduces B.Loop() to replace B.N.
https://pkg.go.dev/testing@go1.24rc2#B.Loop
https://pkg.go.dev/testing@go1.24rc2#B
testing: add testing.B.Loop for iteration #61515
https://github.com/golang/go/issues/61515
As suggested by @rsc, b.Loop could be a clear signal to the com
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
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 standar
The playground, which also serves pkg.go.dev examples. runs in an
isolated environment with just the built test/example binary, without
the source code.
Consider embedding any files you need with "embed" and accessing them
through io/fs.FS rather than through os calls.
- sean
On Fri, Jan 10, 2025
It looks like you're code is failing because you're trying to open from
Your operator is opening new Mboxs and the paths you pass in are assuming
the main.go is called from that directory.
https://github.com/rorycl/mailboxoperator/blob/main/mbox/mbox.go#L28
I'm not sure how you would resolve t
On Mon, Jan 20, 2025 at 7:00 AM Benoît Marguerie wrote:
>
> 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 cr
If I remember well, max(slice...) existed but not anymore: it disappeared
with Go 1.21 I think. The idea was to force one element at least -> why
not, that's the "min/max business" I may say.
But the "unpacking" operator is a builtin and should be allowed for all
func with a variadic input para
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 cm
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 var
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)?
Exam
13 matches
Mail list logo
