[go-nuts] Pointer literal

Hi there, Any HTTP API with PATCH support needs to use pointers on basic types. Therefore I'm wondering if there is any will/proposal to make pointer initialisation easier to work with basic types. The `standard` way is quite verbose so it seems that most APIs use functions for every possible

[go-nuts] reflect, is it possible to get the [body + sign] of a func as text at runtime ?

The body is compiled so you can't get it via reflection. -- 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 to golang-nuts+unsubscr...@googlegroups.com. For more option

[go-nuts] Diff struct

Is there any effort/package/lib that provides diffs on structs with serilization/deserilization methods? I need to store data changes in a db. The db itself (datastore) doesn't provide versions so I need to store the diffs by myself. Currently I'm storing complete copies but they are quite inef

[go-nuts] WebAssembly as a target

I don't think we can expect anything before wasm supports GC (i.e. Phase 3 on wasm roadmap). Once GC is supported(not very soon) Go could be compiled through llgo[0]. One issue could be the binary size(.i.e due /reflect) - Mihai [0] https://llvm.org/svn/llvm-project/llgo/trunk/README.TXT -- Yo

[go-nuts] Unmarshalling and tags

Hi there, I have a struct that needs to be marshalled/unmarshalled using various serialization formats(xml, json, name/value). The tags start to represent a considerable effort[0] so I'm wondering if this is a common use case and if a change[1] to the encoding packages to specify the tag key/se

[go-nuts] Interface{} constrains on specific types

I'm developing a json schema generator (json schema from Go ast and the other way around). There is a keyword "oneOf" which requires exactly one schema to be valid in this keyword's value. In Go I translate it by using an empty interface{}. The issue is that when I convert the interface{} to

[go-nuts] Optional params (RPC)

Is it idiomatic to use pointers on optional fields? I'm developing a RPC API and many resources have optional fields. For example AWS SDK[0] seems to use pointers for all the parameters (received and returned) including the struct fields. Is there any other way(i.e. best practice) to distingui