Re: [go-nuts] inconsistent min max signatures with variadics

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 Ko

Re: [go-nuts] inconsistent min max signatures with variadics

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

[go-nuts] Re: inconsistent min max signatures with variadics

ut 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 >

[go-nuts] Re: inconsistent min max signatures with variadics

he 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)" ? &

[go-nuts] inconsistent min max signatures with variadics

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

Re: [go-nuts] Symbol of const string are not exported by compiler

Just for information, I've written an issue on go compiler to follow this evolution: https://github.com/golang/go/issues/67744 Le vendredi 31 mai 2024 à 10:15:02 UTC+2, Benoît Marguerie a écrit : > Good question ! > > But delve mainly extracts its symbols from Dwarf info. And

Re: [go-nuts] Symbol of const string are not exported by compiler

ng at 0x100086f47 due to protocol error E08 > during memory read for packet $m100086f47,3) > (dlv) print main.constValueStr > Command failed: could not find symbol value for main > > > It is not obvious how Delve is able to resolve "main.constValueInt" since > that s

Re: [go-nuts] Symbol of const string are not exported by compiler

or, in a easier way, a full "copy/paste" example of code: package main import "fmt" const myValueStr = "try" const myValueInt = 12 func main() { fmt.Println("Instruction only to put a breakpoint") } Le jeudi 30 mai 2024 à 10:53:50 UTC+2, Benoît Marg

Re: [go-nuts] Symbol of const string are not exported by compiler

Of course! The code can be really simple like this: *const myValueStr = "try"const myValueInt = 12* *func DoSomething() { fmt.Println("Instruction only to put a breakpoint")}* and the result with delve: *(dlv) print %v myValueInt12(dlv) print %v myValueStrCommand failed: could not

[go-nuts] Symbol of const string are not exported by compiler

Hello All, I discovered a "strange" behavior doing a simple operation. I defined 2 const : one integer and one string. With delve (or other debugger), I'm able to consult the const integer value but not the const string value. Delve team explained me that the go compiler doesn't export symbol