Re: [go-nuts] Practical OpenAPI in Go

Hi Alex, If by "it" you mean the OpenAPI schema or oapi-codegen, then yes to both; I use them in any project that needs HTTP-based APIs whenever the project sponsor allows it, although I wish the code generation of the latter were not so cryptic. If you meant something else, please clarify. -

Re: [go-nuts] Trying to define generic methods to access a memory cache

On Wed, Feb 12, 2025 at 11:34 PM David Karr wrote: > > Ok, good to know. How do I solve this problem? It almost looks like I have to > create a slice of the generic type and iterate through the entries in the > commitsCache result, doing a type conversion of every entry. I don't know what probl

Re: [go-nuts] Trying to define generic methods to access a memory cache

So, for instance, this appears to compile, but I haven't run it yet: func getFromCommitsCache[T any](project string, repo string, branch string) ([]T, bool) { commitsCacheMutex.RLock() defer commitsCacheMutex.RUnlock() var result []T if commits, found := commitsCache[project+"/"+re

Re: [go-nuts] Trying to define generic methods to access a memory cache

Ok, good to know. How do I solve this problem? It almost looks like I have to create a slice of the generic type and iterate through the entries in the commitsCache result, doing a type conversion of every entry. On Wednesday, February 12, 2025 at 2:15:03 PM UTC-8 Jan Mercl wrote: > On Wed, Feb

Re: [go-nuts] Trying to define generic methods to access a memory cache

On Wed, Feb 12, 2025 at 10:54 PM David Karr wrote: `[]any` is a slice type (https://go.dev/ref/spec#Slice_types), not an interface type (https://go.dev/ref/spec#Interface_types). But type assertions, as in `expr.(someType)`, are valid only for interface types: https://go.dev/ref/spec#Type_assert

[go-nuts] Trying to define generic methods to access a memory cache

I don't expect this should be very difficult, go-wise, but I haven't written much code with generics yet. I have an application that can read commits from either github or bitbucket, but each run will either be for bitbucket or github, not both. I have to retrieve the commits for a branch a co

[go-nuts] Re: Practical OpenAPI in Go

Hi Alex, If you're referring to the OpenAPI standard for describing APIs, yes I use that all the time for go services, along with oapigen tool that is referenced in that tutorial. Imo it should sort of be the standard process for building go rest services. I'm actually in the process of buildin

Re: [go-nuts] removing one slice elements from another

Thanks! That did it. On Wednesday, February 12, 2025 at 2:32:27 PM UTC-5 Def Ceb wrote: > The function passed to DeleteFunc should accept a single element and > return a boolean indicating whether it should be removed. > You could do this: > > lhr = slices.DeleteFunc(lhr, func(n uint) bool { re

Re: [go-nuts] removing one slice elements from another

The function passed to DeleteFunc should accept a single element and return a boolean indicating whether it should be removed. You could do this: lhr = slices.DeleteFunc(lhr, func(n uint) bool { return slices.Contains(lhr_del, n) }) Jabari Zakiya: I have two slice, lhr and lhr_dels. I want t

[go-nuts] removing one slice elements from another

I have two slice, lhr and lhr_dels. I want to remove everything in lhr_dels from lhr. I tried these: lhr = slices.DeleteFunc(lhr, func(n uint) []uint { return lhr_del}) or lhr = slices.Delete(lhr, lhr_del) and can't figure out from the error messages|docs how to fix it. Can someone set me strai

Re: [go-nuts] Unused unexported methods kept by DCE when using plugins

I stumbled on https://go-review.googlesource.com/c/go/+/393365 which explains why plugins need to keep unexported methods. Thanks for taking the time to answer my questions, have a good day ! Le mar. 11 févr. 2025 à 15:52, Ian Lance Taylor a écrit : > On Tue, Feb 11, 2025 at 1:57 AM Pierre Gim

[go-nuts] Practical OpenAPI in Go

Curious to know how many of you are using it in your projects. https://packagemain.tech/p/practical-openapi-in-golang -- 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

Re: [go-nuts] Using errors.As error-prone

It's also consistent with the common idiom of errors.New("foo") which returns a pointer (to an unexported type) - although this doesn't appear to be documented, except that "Each call to New returns a distinct error value even if the text is identical" On Wednesday, 12 February 2025 at 09:06:08

Re: [go-nuts] Using errors.As error-prone

On Wed, 12 Feb 2025 at 09:21, cpu...@gmail.com wrote: > I've had some ongoing confusion about using errors.As (see > https://play.golang.com/p/m4_cXCzOViD). The issue I'm having is this part > of the contract: > > > An error matches target if the error's concrete value is assignable to > the valu

[go-nuts] Using errors.As error-prone

I've had some ongoing confusion about using errors.As (see https://play.golang.com/p/m4_cXCzOViD). The issue I'm having is this part of the contract: > An error matches target if the error's concrete value is assignable to the value pointed to by target I always expected (yes, I know), that ba