Daniel Martí

> i feel like the default thing when i encode a node is that i want the representation encoded I fully agree - that's what I've argued before and in...

We could also consider hiding the fields in those generic types, and only exposing the data via methods. This would allow us to prevent misuse (e.g. using `Optional.Value` without checking...

Worth pointing out that it's also possible upstream Go will define an "optional" or "maybe" type of some sort. Some standard library packages like `encoding/json` and `databasel/sql` already have their...

Bonus round: if we retrofit generics, by allowing users on 1.17 or older to manually construct these types like we do with map structs right now, we could add these...

Follow-up thought: we should probably not allow chaining optional and nullable on the Go side, like `Optional[Nullable[Foo]]`. Beyond that perhaps not working, it's also pretty confusing in terms of which...

@rvagg that's correct. The generic helpers for Go 1.18+ would just be for UX; once instantiated, the bindnode APIs would still see the same "flat" types that one can type...

Could the same apply to keys? For example, if I only wanted the values, would I save work by not realizing/building the key nodes? If so, then I'd suggest to...

To me, the advantage of keeping a single iterator instead of splitting into `KeyIterator` and `ValueIterator` is that at each iteration one can decide what nodes need to be obtained....

Personally, I see two options: 1) Force a pointer. Makes map keys and other comparisons harder, but this might be okay if it's always `go-ipld-prime` who creates the `cidlink.Link` pointers....

Could you show a quick example of how the simplest use of the new API would look like? A diff on the "intro to Go" I wrote, for example, could...