Roger Peppe

Currently anonymous fields aren't supported in Go struct types. They probably should be.

We could just ignore calls that fail, rather than panicking, reasoning that those types are going to fail when used anyway.

Currently if a Go int type uses string values that aren't compatible with the Avro [name restrictions](https://avro.apache.org/docs/1.9.1/spec.html#names), it won't be treated as an enum, when it potentially could be if...

use fully qualified names for Go types

1

We're currently only using the base Go type name as the Avro name, but this can lead to name clashes if there are two types of the same name from...

We could potentially support decoding into `interface{}` values, where what's inside the value is filled in from the writer schema. This would provide an idiomatic and consistent way to inspect...

Currently if reading an integer type into a Go type that's smaller, we can get a silent overflow. We should check that and error if it happens. See relevant TODO...

It would be nice to be able to check type compatibility. A possible API: ``` // CompatMode defines a compatiblity mode used for checking Avro // type compatibility. type CompatMode...

Both maps and slices can already be nil, so perhaps we could encode the union `["null", {"type": "map", "values": "int"}]` as `map[string]int]` not `*map[string]int` as we do currently. But this...

Currently if you've got several records with matching names (but different namespaces), you'll get an error because we'll generate duplicate Go types. We could allow `avro-generate-go` to specify a mapping...

We'd like to support OCF files, and potentially other kinds of streamed Avro record files. Possible API: ``` // NewEncoder returns a new Encoder instance that encodes // a stream...