Re: [go-nuts] Re: When will the official encoding/json package support parsing json5？

On Mon, Mar 21, 2022 at 6:00 AM jan.f...@gmail.com wrote: > Just googled for "json5 golang" and there seem to be several 3rd party > implementations available. > Can you not use one of those? See also HuJSON, also known as "JSON With Commas and Comments": https://github.com/tailscale/hujson

[go-nuts] Re: When will the official encoding/json package support parsing json5？

Just googled for "json5 golang" and there seem to be several 3rd party implementations available. Can you not use one of those? söndag 20 mars 2022 kl. 14:27:05 UTC skrev Brian Candler: > If you're going down that route, you could also consider jsonnet > (which does have

[go-nuts] Re: x/exp/slices: add Map/Extract function

On Sunday, 20 March 2022 at 18:14:15 UTC+1 cpu...@gmail.com wrote: > Has this already been discussed? > Yes: https://github.com/golang/go/discussions/47203#discussioncomment-1005237 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] x/exp/slices: add Map/Extract function

Playing with 1.18 I've noticed that I can immediately replace pretty much all uses of https://github.com/thoas/go-funk with the new slices package. One common use case that I happen to have in the codebase quite a lot is extracting data from a slice of objects: funk.Map(chargers, func(c

Re: [go-nuts] Is there a way to eliminate the code repetition in the code?

I don't think so. https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-way-to-express-convertibility Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] Re: type parameters and named type

> *type parameters *itself is not a type, but a list of type parameters. true. The spec means a single type parameter is a named type. On Monday, March 21, 2022 at 12:12:26 AM UTC+8 xiej...@gmail.com wrote: > Hi there. > > I am reading go spec. When hit the "Types" section, > >

[go-nuts] Is there a way to eliminate the code repetition in the code?

package main type A interface { Ma() } type B interface { Mb() } type Ta struct { A } type Tb struct { B } func ConvertSliceToA[From A](vs []From) []A { var r = make([]A, len(vs)) for i := range vs { r[i] = vs[i] } return r }

[go-nuts] type parameters and named type

Hi there. I am reading go spec. When hit the "Types" section, https://go.dev/ref/spec#Types it stated "Predeclared types, defined types, and type parameters are called named types." I wonder why "type parameters" is "named type". To find the definition of this term, I found section

[go-nuts] Re: When will the official encoding/json package support parsing json5？

If you're going down that route, you could also consider jsonnet (which does have a Go implementation ) It will almost certainly be much more powerful than you need, but it *is* another superset of JSON which includes comments. On

[go-nuts] Re: about keyword constraint?

For background information, Featherweight Go The Go language famously lacks generics. Our paper introduces a core formal model of Go, Featherweight Go (FG), and explores a design of generics for FG featuring structural typing (Featherweight Generic Go). The semantics of generics are defined

[go-nuts] Re: When will the official encoding/json package support parsing json5？

You might want to try qjson that I wrote a year ago (https://github.com/qjson). It's basically just one function that converts qjson text into json. Qjson is inspired by hjson, but extend it in many ways. It is convenient for config files. Maybe I extend it a bit too far by supporting

Re: [go-nuts] about keyword constraint?

I don't think `constraint` was ever removed. We had `contract` in the design at some point, and some people suggested to add `constraint` to replace it, but it never got done, so it could never have been removed. As to the reason why `contract` was removed and why `constraint` was not added: When

Re: [go-nuts] about function argument type infer?

On Sun, Mar 20, 2022 at 12:20 PM xie cui wrote: > why use function argument type infer, and why function argument type infer > int to []int? > Because the signature says `[]E`. So, the inference tries to determine `E`, infers it to be `int` and then substitutes that into the return type to make

[go-nuts] about function argument type infer?

package main import ( "fmt" "reflect" ) import "golang.org/x/exp/constraints" // Double returns a new slice that contains all the elements of s, doubled. func Double[E constraints.Integer](s []E) []E { r := make([]E, len(s)) for i, v := range s {