GoCodeWriter's $T and $P generate unexpected types for list and maps. #149
Labels
enhancement
New feature or request
Comments
Merged
1 task
jasdel
added a commit
that referenced
this issue
Nov 15, 2020
…#232) Adds a new KnowedgeIndex implementation GoPointableIndex this index declares when a shape should be a pointer or value type in Go code. Updates the SDK's code generation so that all non-sparse list and maps are rendered with value members instead of pointers. This null-ability applies to number and boolean members to that are not explicitly decorated as boxed. Fixes #128 Fixes #127 Fixes #149
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should take a look at how slice/map types are generated from
$T, and$P. If a member is or is not a pointer of a slice/map should not be driven by$T, or$P, the member being a pointer is driven by the modeled list/map shape, and its member.This mean that
$Tshould generate the correct Go type for a map of strings, i.e.map[string]*string. In addition the same for lists (assuming lists cannot be sparse, i.e.[]string. Using$Pshould generate the pointer type of the outer shape,*map[string]*stringand*[]string.$Pshould have no impact on the generate of nested members within collections.The text was updated successfully, but these errors were encountered: