Re: [go-nuts] Compile-time control flow with type inference

It's not clear to me, what W1 and R1 are in your example. But FWIW, Go has no way to do compile-time meta programming and is unlikely to ever get one. It interacts too poorly with the goal of predictably fast compile times and the general safety assumptions of Go (you can run `go build` and be sur

Re: [go-nuts] The usage of method call syntax for regular functions as a way to have "generic methods"

I'll make one more note, in an attempt to show that this problem is not easy to solve: Rust has generic methods. But it does not allow to use them in a "trait object" (it calls that "object safety"). Go's interfaces are, primarily, equivalent to Rust trait objects. The fact that Rust has not figure

Re: [go-nuts] The usage of method call syntax for regular functions as a way to have "generic methods"

On Sun, 3 Nov 2024 at 04:52, Mark Mavzon wrote: > 1. For an interface's generic methods disallow the use of "any" constraint > for type parameters. > type HasIdentity interface { > Identity[T int64 | float64](T) T // ok > // Identifoo[T any](T) T // not allowed > } > I'll note that this is

Re: [go-nuts] The usage of method call syntax for regular functions as a way to have "generic methods"

>From an off-list response: 1. It only works if the function is defined in the same package as its >> used, or you'd need to use dot-imports. > > The dot-import in this case seems redundant because we have a variable > with which we try to use a method syntax and this variable has a specific > typ

Re: [go-nuts] The usage of method call syntax for regular functions as a way to have "generic methods"

The chained syntax does not contain a package name. There are three possibilities 1. It only works if the function is defined in the same package as its used, or you'd need to use dot-imports. Neither is likely to be acceptable. 2. There would be an ambiguity, if multiple imported packages define a

Re: [go-nuts] math.Abs vs if value < 0

It gives a different result for -0: https://go.dev/play/p/LAVIaAZsVNi Also, the math.Abs implementation is branch-less. Depending on what the compiler makes of either, that might perform better. On Sat, 19 Oct 2024 at 16:28, Diego Augusto Molina < diegoaugustomol...@gmail.com> wrote: > Hi! I want

Re: [go-nuts] GoImports version

Damn, I keep forgetting that I had other stuff to say: My main concern with this approach is that the BuildInfo embedded into binaries is incomplete in a bunch of circumstances - for example, if you clone the repository and run `go build` in it (I believe) or if someone uses a `goimports` version w

Re: [go-nuts] GoImports version

On Fri, 18 Oct 2024 at 08:20, Kurtis Rader wrote: > And, obviously, how do you handle a command named "goimports" installed by > the user that is not from the golang.org/x/tools repository. > I'll note that it should be trivial to check if the BuildInfo.Main.Path is golang.org/x/tools and BuildI

Re: [go-nuts] GoImports version

I tried it out and the format parsed by debug.ParseBuildInfo is almost exactly what is output by go version -m: https://go.dev/play/p/L-MNzr0EnjV (and yes, my goimports version is old) On Fri, 18 Oct 2024 at 08:20, Kurtis Rader wrote: > On Thu, Oct 17, 2024 at 10:31 PM shan...@gmail.com > wrote

Re: [go-nuts] GoImports version

You can look at `go version -m /path/to/goimports` to get the version of the golang.org/x/tools module. I seem to remember that there was a way to get that information out of a binary programatically as well, but I can't find it right now. You might try to look at what the `go version` command does

Re: [go-nuts] Re: good practice or premature optimization

If you write `_ = s[10]` and len(s)<11, that line will panic. So after that line, the compiler can assume that len(s)>=11 and omit bounds check for smaller indices. That is, if you write f(s[0]) f(s[1]) … f(s[10]) That will be 11 bounds checks, as depending on what exactly len(s) is, a different

Re: [go-nuts] Using structs, pointers, and maps

t;> race calling the value methods. It must afaik as the runtime/compiler has >>>> no implicit synchronization when creating the copies. That is a data race. >>>> >>>> On Oct 7, 2024, at 5:10 PM, Axel Wagner >>>> wrote: >>>> >>>&g

Re: [go-nuts] Using structs, pointers, and maps

On Wed, 9 Oct 2024 at 10:42, 'Brian Candler' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Tuesday 8 October 2024 at 07:37:25 UTC+1 Axel Wagner wrote: > > the only one on the "mixing receiver kinds is sometimes necessary, so we > shouldn't caution against it" side of the table > > >

Re: [go-nuts] Using structs, pointers, and maps

> But to repeat my actual argument in favour of (sometimes) mixing receiver >> kinds: >> 1. It is totally reasonable to use some types as values. >> 2. Such types, intended to be used as values, will need to use >> value-receivers for some methods, as otherwise the

Re: [go-nuts] Using structs, pointers, and maps

implement > functionalities like unmarshalling. > > time.Time is a standard library example of such a type. I also provided an > example for an "enum-like" type implementing flag.Value. > > On Mon, 7 Oct 2024 at 23:57, Robert Engels wrote: > >> I am pretty sure

Re: [go-nuts] Re: Using structs, pointers, and maps

ess you do it > externally (which is a huge pain to do everywhere). > > On Oct 7, 2024, at 4:43 PM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >  > No offence, but I made an argument. You don't have to agree with the > argument

Re: [go-nuts] Re: Using structs, pointers, and maps

> Em segunda-feira, 7 de outubro de 2024 às 15:15:25 UTC-3, burak serdar > escreveu: > >> Mixing pointer and value receivers can be race-prone, because of the >> copying involved in passing value receivers. >> >> On Mon, Oct 7, 2024 at 12:03 PM 'Axel Wag

Re: [go-nuts] Re: Using structs, pointers, and maps

To be honest, I always found this recommendation a little bit strange, personally. I'll note that the standard library does not really keep to this either. For example, time.Time.UnmarshalText (obviously) has a pointer-receiver, while almost all other methods on time.Time have a value receiver. An

Re: [go-nuts] go test cache: include umask as a test input for caching?

I think you are probably going to get better results by just filing a proposal. That's the normal process which will end in a definite result one way or the other, while mailing list threads tend to go in circles, eventually. On Tue, 17 Sept 2024 at 13:08, twp...@gmail.com wrote: > > On Tuesday,

Re: [go-nuts] go test cache: include umask as a test input for caching?

On Tue, 17 Sept 2024 at 10:33, twp...@gmail.com wrote: > umask cannot be set in subtests for two reasons: > 1. It is a process-wide global variable stored by the operating system. > Changing the umask in a test changes the umask for the entire process, i.e. > it changes the umask for all tests. >

Re: [go-nuts] Suppress GoFmt-generated error with/tools.go?

On Sat, 31 Aug 2024 at 14:22, Mike Schinkel wrote: > Hi Alex & Peter, > > Thank you both for your replies. > > On Aug 30, 2024, at 2:43 AM, Axel Wagner > wrote: > I don't think that error message comes from gofmt. As far as I am aware, > gofmt only parses source code, it does not even do type-ch

Re: [go-nuts] Suppress GoFmt-generated error with/tools.go?

Hi, I don't think that error message comes from gofmt. As far as I am aware, gofmt only parses source code, it does not even do type-checking. That is intentional - in general, Go tools tend to avoid relying on stronger assumptions than they need. So I would assume that this error message is produ

Re: [go-nuts] Add yield types for range over function

I don't really understand the question. What I'm saying is 1. we don't want them to be defined types, because of the issue I described, so 2. it probably needs to be possible to have generic type aliases first and 3. once that is possible, we might add `Yield` and `Yield2` as type-aliases to the `i

Re: [go-nuts] Add yield types for range over function

The plan is, to introduce type-aliases in the `iter` package: type Yield[E any] = func(E) bool type Yield2[K, V any] = func(K, V) bool The reason to make these type-aliases instead of defined types is that it should be possible to define iterators without needing to import the `iter` package. But w

Re: [go-nuts] first class iterator values?

Or with half the allocations: https://go.dev/play/p/LmtNdR-hfWY I can't get it down to 1 allocation, which should be the theoretical minimum, as I can't get the compiler to move the closure and the state being closed over into one allocation. On Fri, 16 Aug 2024 at 11:43, Axel Wagner wrote: > Yo

Re: [go-nuts] first class iterator values?

You can also use reflect to get non-restartable map-iterators. It has some additional setup cost, but I don't think it's *a lot* and after that it should be relatively cheap. https://go.dev/play/p/vUec8AYhFPa On Fri, 16 Aug 2024 at 09:34, Costanza, Pascal wrote: > I haven’t double-checked, but a

Re: [go-nuts] After Disbanding the Python Team, Google’s Go Team Faces Turmoil: Technical Lead and 12-Year Project Leader Steps Down

The facts of the title are correct. See here: https://techcrunch.com/2024/05/01/google-lays-off-staff-from-flutter-dart-python-weeks-before-its-developer-conference/ https://groups.google.com/g/golang-dev/c/0OqBkS2RzWw However, mentioning these in the same sentences seems to drum up a storm in a wa

Re: [go-nuts] generic multitype inference, some but not others

That is not possible, currently. You can only omit type parameters from the end of the list, to have them inferred. So, in your case, you are going to have to specify all type parameters. On Sat, 10 Aug 2024 at 19:26, 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > any supp

Re: [go-nuts] Request for Removal of Problematic Version: github.com/alibabacloud-go/ecs-20140526/v4 v4.24.17

Hi, I believe module retraction was designed for this specific use case. It allows you to mark a specific version as defective, without breaking any builds or anything - and without requiring manual intervention by any module proxies. Note, in particula

Re: [go-nuts] might be a hole in Golang specification regarding the definition of "addressable"

Hi, > However, I would like to point out that selector rule 3 states: > > As an exception, if the type of x is a defined pointer type and (*x).f is > a valid selector expression denoting a field (but not a method), then x.f > is shorthand for (**x).f.* > > The emphasis here is on "defined pointer

Re: [go-nuts] might be a hole in Golang specification regarding the definition of "addressable"

Oh, I only just realized that "pointer indirection" is literally in that list of addressable things. For some reason I have overlooked that, even after re-reading the section of the spec several times. That really makes this clear. On Wed, 17 Jul 2024 at 06:51, Ian Lance Taylor wrote: > On Tue,

Re: [go-nuts] Potential Issue in errgroup

(sorry, didn't hit "Reply All", apparently) Hi, I don't believe the semaphore has anything to do with the wait group counter. So I don't believe it is relevant to this question. Note that a goroutine can be interrupted at any time anyways, so whether or not that code is there doesn't matter for c

Re: [go-nuts] How does bytealg.MakeNoZero() work?

And in terms of practical advice: You might be able to use go:linkname yourself to get access to that functionality from the runtime. But note that go:linkname is being locked down in Go 1.23 , so that is not a future-proof plan. Your best bet is probabl

Re: [go-nuts] How does bytealg.MakeNoZero() work?

It is defined in the runtime and go:linkname'd into the bytealg package: https://github.com/golang/go/blob/90bcc552c0347948166817a602f612f219bc980c/src/runtime/slice.go#L394 >From the spec : > A function declaration without type parameters may omit t

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

Hi, you might be interested to learn that Ian has filed a CL adding an FAQ entry . On Thu, 20 Jun 2024 at 16:18, Oliver Eikemeier wrote: > Thanks for that example. > > The issue is that you and I have constructed aliased variables that the

Re: [go-nuts] Go import redirect docs are unclear

The meta tag I gave differs from the meta tag the documentation gave. On Mon, 24 Jun 2024 at 02:50, will@gmail.com wrote: > >Most web servers automatically serve an `index.html` for a request to a > directory. The intent is to use something like that. Though note that you > can also use a fu

Re: [go-nuts] Go import redirect docs are unclear

On Sun, 23 Jun 2024 at 16:17, Tobias Klausmann wrote: > Hi! > > On https://pkg.go.dev/cmd/go#hdr-Remote_import_paths, in the section > about using meta tags to redirect from some domain to a known forge, it > says: > > > For example, > > > > `import "example.org/pkg/foo"` > > > > will result in t

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

I want to re-emphasise that both of these examples violate the allowed usages of unsafe.Pointer defined by gc. So I would argue that, yes, its expectation is reasonable, because it explicitly told you not to create this situation. If you can construct a program that does not violate the unsafe.Poi

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

FYI, filed https://github.com/golang/go/issues/68086 for the spec-hole that conversions between unsafe.Pointer and other pointer types are not implementation defined. On Thu, 20 Jun 2024 at 14:12, Axel Wagner wrote: > > > On Thu, 20 Jun 2024 at 13:48, Oliver Eikemeier < > eikeme...@fillmore-labs

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

On Thu, 20 Jun 2024 at 13:48, Oliver Eikemeier wrote: > > Am 20.06.2024 um 13:24 schrieb Axel Wagner >: > > We can see that 1. `unsafe.Pointer` is definitionally a pointer type, 2. > in your example, the two `unsafe.Pointers` do not point to the same > variable and do not have the value `nil` an

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

ation should be adapted, for clarity but also >> for the fact that only one pointer pointing to a zero-sized variable can >> compare differently to anything over time, even things having the same >> address value. >> > > Note that "address value" is not som

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

e. And as above, I'm not sure how to clarify it further, while still leaving up the space we want to left open. > > I do not believe the specification is clear on this. Otherwise I don’t > think this is urgent. But it seems to pop up repeatedly. > > Cheers > Oliver > > A

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

On Wed, 19 Jun 2024 at 22:43, Oliver Eikemeier wrote: > The specs says, as you say above, "Pointers to distinct zero-size > variables may or may not be equal.” That means that you can't predict > the result of any given comparison of addresses of zero-sized > variables. > > > I'm not sure I read

Re: [go-nuts] variable set in a loop but unused not failing compilation

Hi, I'll note that this has nothing, really, to do with the loop, but with the fact that you are assigning a struct field. For a simpler example, compare this: https://go.dev/play/p/MmR-AhOUQH3 with this: https://go.dev/play/p/Y1uoI8thYuV If you only write to the entire variable, the compiler comp

Re: [go-nuts] problem with generic type switch

Yes, the *underlying type* of Class is `byte`, but the type-switch checks if the dynamic type is *exactly* `byte`. The only way, currently, to implement the kind of check you want is to use reflect: switch rv := reflect.ValueOf(v); rv.Kind() { case reflect.Uint8: // byte v := uint8(rv.Uint())

Re: [go-nuts] [generics] type constraint for structs

How does `interface{ AsElement() *Element }` not do exactly what you want? On Thu, Apr 4, 2024 at 4:14 AM atd...@gmail.com wrote: > Might have come across this today as I was trying to simplify some code. > > Basically, I have a base type called *Element that has a method > AsElement() *Element

Re: [go-nuts] Module vs Package

A package is the unit of compilation - the entire package is compiled in a step and it's also where unexported names are scoped to. A module is the unit of versioning - it's a bunch of packages versioned and distributed together. On Mon, Apr 1, 2024 at 8:43 AM Nikhilesh Susarla wrote: > Packages

Re: [go-nuts] Nil pointer panic that should be impossible

of that field. >>> >>> I don't know if that helps, it's a bit subtle. >>> >>> On Mon, Mar 25, 2024 at 1:35 PM 'Lirong Wang' via golang-nuts < >>> golan...@googlegroups.com> wrote: >>> >>>> Wow, i am from ot

Re: [go-nuts] Nil pointer panic that should be impossible

something like that, so thread-safe for this operation. learned >>> something new!!! Thanks >>> On Thursday, March 21, 2024 at 11:42:24 PM UTC+8 Ethan Reesor wrote: >>> >>>> I hadn't used the race detector before. I do see a race warning for >>>>

Re: [go-nuts] Nil pointer panic that should be impossible

;> (*URL).String() among an embarrassing number of other results. I'm going to >> update (*URL).String() to use atomic.Pointer to remove the race. >> >> Thanks, >> Ethan >> >> On Thu, Mar 21, 2024 at 8:59 AM 'Axel Wagner' via golang-nuts &l

Re: [go-nuts] Nil pointer panic that should be impossible

On Thu, Mar 21, 2024 at 2:48 PM 王李荣 wrote: > hi Axel, > > is not modifying `u.memoize.str` thread-safe? the len and the data point > should become visible at same time? > What makes you think that? To be clear, there are no benign data races. Even a data-race on a variable smaller than a word i

Re: [go-nuts] Nillable basic types?

FWIW I believe (as Brian sort of points out) this proposal is fully subsumed under #57644 . Under that proposal, the proposed type `int | nil` would be spelled `interface{ int }`. The other syntactical constructs are, as far as I can tell, identical - you'

Re: [go-nuts] Nil pointer panic that should be impossible

Have you tried running the code with the race detector enabled? I suspect that you are concurrently modifying `u.memoize.str` by calling `u.String()` from multiple goroutines. And the non-zero length of the string header written by one goroutine becomes visible to the other one, before the modifica

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

On Thu, Feb 29, 2024 at 9:12 AM kredop...@gmail.com wrote: > Apologies - sent the response only to you, so I'll write it again here. > > > Doesn't the `go install` command explicitly instruct you to add > $GOBIN/$GOPATH/bin to your $PATH? > > I did check both golang installation docs and the outp

Re: [go-nuts] Equality of interface of an empty struct - why?

change for > the same values because of the assumption that pointers never change. This > is implied by the spec but easy to miss. > > "Pointers to distinct zero-size variables may or may not be equal." > "Pointers to distinct zero-size variables may or may not be equal

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

Doesn't the `go install` command explicitly instruct you to add $GOBIN/$GOPATH/bin to your $PATH? To me, that seems enough - it feels a bit arduous, to expect this piece of information at any single point on the web where `go install` is mentioned. On Thu, Feb 29, 2024 at 1:39 AM Robert Sawicki w

Re: [go-nuts] Equality of interface of an empty struct - why?

nters to distinct zero-size variables may or may not be equal and the >> results may or may not be repeatable in any context." >> >> Agree once a programmer is aware of the behavior it can be avoided. >> >> Best, >> Brien >> >> >> On Feb 27, 20

Re: [go-nuts] Equality of interface of an empty struct - why?

On Tue, Feb 27, 2024 at 8:19 PM Marvin Renich wrote: > Prior to generics, the type of the > arguments to == were easily known to the programmer, and so it was > obvious when this "undefined" exception would raise its ugly head, and > you just didn't use it for empty struct types. But now, with g

Re: [go-nuts] Equality of interface of an empty struct - why?

On Mon, Feb 26, 2024 at 7:25 PM Brien Colwell wrote: > Interesting. That seems to break the comparable spec. > > >> Pointer types are comparable. Two pointer values are equal if they > point to the same variable or if both have value nil. Pointers to distinct > zero-size variables may or may not

Re: [go-nuts] Re: Equality of interface of an empty struct - why?

I think you should still wait for the outcome of that issue. On Mon, Feb 26, 2024 at 10:39 AM brien colwell wrote: > I learned a lot from this thread, thank you. > > Intuitively the spec seems to conclude a pointer to an empty struct is a > different type of pointer? Normally a pointer wouldn't

Re: [go-nuts] Equality of interface of an empty struct - why?

FWIW I believe there is enough subtlety here (small changes in the code might trigger different compiler optimizations) that I wouldn't rely too much on probing the compiler with different programs. Instead, I'd suggest decompiling the binary and/or running it in a debugger, to check what the actua

Re: [go-nuts] Equality of interface of an empty struct - why?

>From the spec : > A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory. On Thu, Feb 22, 2024 at 11:

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

On Wed, Feb 21, 2024 at 1:36 AM Sam Vilain wrote: > I had a brief look on the Golang issues in Github and could not find any > prior proposals along this line using "context" and "dynamic scope" as > search terms, so I'll submit this as a "new" proposal for now > FWIW some prior discussion on th

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

If I may quote myself: > And no matter which choice you make for the language - it means that if the programmers wanted the other, they'd have to jump through annoying hoops and get confusing and hard to debug problems. Having a mechanism to get one or the other semantic doesn't change the fact t

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain wrote: > I would argue that the matter can be simply decided by choosing the > *calling* stack, not the destination stack. > I agree that this is *one choice*. But the point is, that *sometimes* you'd want one and *sometimes* the other. And no matter wh

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

FWIW the common name for this is "dynamic scope": https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynamic_scope The general reason this has not been accepted for Go, is that passing a Context explicitly removes ambiguities what is meant, in the presence of closures and goroutines. If you pa

Re: [go-nuts] "yield" is backwards

I'm not sure what you mean. The `yield` function does exactly the same as Python's `yield` statement and in fact, that's part of why the name was chosen. Compare Python: def vals(a): for v in a: yield v for x in vals([1,2,3]): print(x) With Go: func vals[T any](s []T) iter.

Re: [go-nuts] New type in generics

The way to do that is to add another level of indirection (as everything in Software Engineering): type Namer[T any] interface { *T SetName(name string) } func WithName[T any, PT Namer[T]](name string) T { var v T PT(&v).SetName(name) return v } I will say, though, that it's n

Re: [go-nuts] Does building with an older golang use package sources from that older version?

You don't even need to run `go clean`. Go will automatically detect whether stuff needs to be rebuilt, as the Go version used to build a package is part of a hash, that is used as a key for the build cache. And yes, it will use the standard library packages of the Go version that is installed (the

Re: [go-nuts] Type parameter embedded field

I think that might work, yes. At least I don't see a major issue with it right now. On Tue, Jan 9, 2024 at 7:25 PM roger peppe wrote: > > > On Fri, 5 Jan 2024 at 05:58, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >>

Re: [go-nuts] Incorrect "missing return" error for an edge case

The "missing return" error is defined in the spec, by requiring a function to end in a terminating statement: https://go.dev/ref/spec#Terminating_statements The list is necessarily not complete. So it is necessarily more advisory than anything else. What things to put in is mainly limited by how mu

Re: [go-nuts] Type parameter embedded field

Hi, I think the reason this has not happened is that it makes code using such a type invalid, depending on the type-argument - in ways not captured by the constraint. For example: type X[T any] struct { T *bufio.Reader } func main() { var x X[int] x.Read // definitely refers to X.

Re: [go-nuts] How to create a generic factory?

Note that your code is not type-safe. It panics when instantiated with a type that does not use a pointer receiver: https://go.dev/play/p/eHUKtXvgwAu ISTM that being more type-safe would be an advantage here. On Sat, Dec 30, 2023 at 8:47 PM Mazen Harake wrote: > @Alex, > > Oh, and I should point

Re: [go-nuts] How to create a generic factory?

1. Note that you can just write `NewMessage(&MessageA{}, buf)` in your example, as the type can be inferred. 2. You can use a constraint on a pointer-receiver to somewhat simplify that: https://go.dev/play/p/pEu02Bn9t3f That is not *quite* what you are asking for. It is not actually possible to rea

Re: [go-nuts] Re: Why there is no net.ListenContext?

Hm, reading again, I don't think I actually understand your question. You clearly are ListenConfig aware. But what do you mean with "the same way we have Dial and DialContext"? These are methods on Dialer, so ISTM that there is indeed a pretty clear correspondence. Except that Dialer.Dial has been

Re: [go-nuts] Re: Why there is no net.ListenContext?

You can use `ListenConfig.Listen` to do this: https://pkg.go.dev/net#ListenConfig.Listen I believe the reason to do it this way was the realization that there will probably be more ways to set up listening in the future and having lots of different ListenFoo functions in the package would overload

Re: [go-nuts] slog formatter funcs? (e.g. slog.Infof)

I believe the intention is that you shouldn't format this, but make `err` an `Attr`. i.e. the philosophy behind structured logging is specifically, not to do formatting, as it produces unstructured data. Whether I'm personally convinced by that philosophy is another question, but I think that's the

Re: [go-nuts] Generic type for struct method: constraint problem && cannot use (untyped string constant) as string value

I agree that it is an unfortunate error message, but to be clear, it is entirely correct - you are defining a new type called `uint8` and it is indeed not possible to assign an untyped integer constant to that, as its underlying type is a type parameter (constrained on any). I'm pretty sure there

Re: [go-nuts] Generic type for struct method: constraint problem && cannot use (untyped string constant) as string value

Yes, this has come up before. On Fri, Nov 10, 2023 at 7:09 AM ahuigo wrote: > There is an example: https://go.dev/play/p/guzOWRKi-yp > > ``` > func (c *cachedFn[string, V]) Get0() (V, error) { > // var s any > var s string > s = "abc" // error: cannot use "abc" (untyped string constant) as strin

Re: [go-nuts] Can Generics match implementers of an interface?

ite less and less that invent > generics...? ¿I'm the lazy one that rants for having to learn new types > theory? > > and After a few drinks: First Object class now interface{} struct... > you both have everything... generics... keep it simple please... don't > be

Re: [go-nuts] Can Generics match implementers of an interface?

I think addressing this would sensibly include a rule to allow unifying two types, if one is assignable to the other (which, AIUI, we already do for directional channels). It's possible that this can be confusing in some circumstances including composite types e.g. something like func Append[T an

Re: [go-nuts] Can Generics match implementers of an interface?

This is purely a type-inference problem. If you explicitly instantiate `Append`, it works: https://goplay.tools/snippet/15RFAPFPl3y Type inference is still relatively limited. It might become possible to at some point omit the instantiation. I think this might be "Inferring based on interfaces" in

Re: [go-nuts] Can we not invoke methods on types referring to generics?

On Fri, Oct 20, 2023 at 1:07 PM Nurahmadie Nurahmadie wrote: > This statement doesn't feel right to me, one can always do `type NewType > struct{}` to create genuinely new types, but if you do `type String > string`, for example, surely you expect String to has `string` value, hence > there will

Re: [go-nuts] Can we not invoke methods on types referring to generics?

FWIW I think what OP is ultimately asking about is some form of nominal subtyping. When they say "automatic upcasting", they refer (I believe) to what Go calls "assignability", which is in essence a subtype relationship. So they want to be able to define a new type, that is a subtype of an existing

Re: [go-nuts] Generic "nillable" constraint

On Wed, Oct 18, 2023 at 5:24 PM Jon Watte wrote: > I think "making all values comparable" is a worse change though (there's a > reason they aren't comparable!) > FTR the proposal was not to make all values comparable, but to make all values comparable to the predeclared identifier nil - similar

Re: [go-nuts] Generic "nillable" constraint

On Wed, Oct 18, 2023 at 6:09 AM Jon Watte wrote: > Circling back to this, because it came up today again. > > Here's the generic function I want to write. It comes up in a lot of > function composition, which in turn comes up in a lot of interface adapters > and such: > > func maybeAssign[T any](

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

It is not "meant for tests internal to the http package". It's meant for tests of users of the `net/http` package. That is, implementations of the `http.Handler` interface. In the context of the standard library, that is what "general purpose HTTP testing" means. On Tue, Oct 17, 2023 at 10:44 AM S

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

To be clear: The behavior of an `http.ResponseWriter` to implicitly use a 200 status code if no explicit WriteHeader call is made is documented: https://pkg.go.dev/net/http#ResponseWriter.WriteHeader I really think it is a bad (or at least strange) idea to claim to implement `http.ResponseWriter` w

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

It seems to me that the fact that the functions accept and return types from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given that it's nested below `net/http` should make it fairly obvious that it's meant to be used with `net/http`. I also genuinely don't understand what the in

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

If you want to argue that `net/http` should not set the response code to 200 by default, I would be inclined to agree. I don't particularly like that the API even *allows* you not to explicitly set a response code. But it does. And while it does, the best test is one that matches the behavior of th

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

A default `net/http` server also uses 200 as the default response code. The behavior of an `http.Handler` not setting a response code should be the same, if it uses `httptest`, as if it uses `net/http`. On Sun, Oct 15, 2023 at 5:17 PM Simon Walter wrote: > Hi all, > > What is the reason that Res

Re: [go-nuts] Re: Why causes []any trouble in type equations?

On Wed, Oct 11, 2023 at 8:11 PM Torsten Bronger < bron...@physik.rwth-aachen.de> wrote: > Then, all boils down to the fact that you can’t pass []float64 as an > []any. To be honest, I still don’t fully understand why this is > forbidden What would this do? func F(s []any) { s[0] = "Foo" }

Re: [go-nuts] Re: Why causes []any trouble in type equations?

In the first example, the inferred type is `float64`, so the signature of the function is `func do([]float64)`. You can obviously pass a `[]float64` to it. If X is a concrete (i.e. non-interface) type, then `func F[T X]()` is syntactic sugar for `func F[T interface{ X }]()`, which is a constraint t

Re: [go-nuts] Why causes []any trouble in type equations?

In the second case, the type argument is inferred to be `[]float64`. The constraint on `T` in `do` is that it has to be `[]any`. `[]float64` is not `[]any`, the two are different types, so instantiation fails. Note that even if you explicitly instantiate `do` to `[]any`, you still could not pass a

Re: [go-nuts] The docs for secretbox seem very wrong

I get the impression that the thing you are missing is that appending to a slice does not modify it. That is, `append(s, x...)` modifies neither the length, nor the content of `s`, you have to type `x = append(s, x...)`. `Seal` (and `Open`) work exactly the same. They append to the `out` parameter

Re: [go-nuts] The docs for secretbox seem very wrong

For what it's worth, here is an example that demonstrates a typical encryption/decryption roundtrip, perhaps more clearly: https://go.dev/play/p/ZZry8IgTJQ_- The `out` parameter can be used to make this more efficient by using pre-allocated buffers (depending on use case) and there are cases where

Re: [go-nuts] The docs for secretbox seem very wrong

oh I forgot to emphasize: I don't believe the output is *really* ``. That is, I don't believe you can really treat the first N bytes as the encrypted text and decrypt it (say, if you didn't care about the authentication). It's just that you ultimately need to add 16 bytes of extra information to ca

Re: [go-nuts] The docs for secretbox seem very wrong

I don't really understand your issue. You call encrypted := secretbox.Seal(nonce[:], []byte(s), &nonce, &secretKey) That means you pass `nonce[:]` as the `out` argument, `s` as the `message` argument, and the nonce and key and assign the result to `encrypted`. According to the docs of `secretbox`,

Re: [go-nuts] Generic "nillable" constraint

Oh (sorry, being forgetful) and re "it's less of a new mechanism than introducing a zero identifier": #62487 introduces *even less* new mechanism, by expanding comparison to (and assignment of) `nil` to all types inside a generic function. It's not a new

Re: [go-nuts] Generic "nillable" constraint

(correction: It should be Convert[J isinterface, T J]. I changed the name from I to J to be more readable and then missed one occurrence) On Wed, Oct 4, 2023 at 7:33 AM Axel Wagner wrote: > On Wed, Oct 4, 2023 at 6:54 AM Jon Watte wrote: > >> > where it is important to permit only type argument

  1   2   3   4   5   6   7   8   9   10   >