Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Stencil - Simple code templating for Go #1

sridharv opened this issue Jun 26, 2017 · 0 comments

Proposal: Stencil - Simple code templating for Go #1

sridharv opened this issue Jun 26, 2017 · 0 comments


Copy link

@sridharv sridharv commented Jun 26, 2017

The Proposal

  • The generic unit is a package.
  • Specialise a package by substituting one type for another.
  • Import statements define type substitutions. example/num/float64/float32 is example/num with float64 replaced by float32.
  • Generate specialised versions of the packages in a vendor directory.
  • Use the closest vendor directory. If none exist create one.
  • Perform type substitutions with a tool that scans files for these import statements.
  • Use the tool as a format-on-save command in the editor, or run it with go generate.
  • The tool uses type inference to automatically add missing imports with type substitutions.
  • Refer to source packages as stencils. Refer to specialised versions as stencilled packages. The words “generics” and “templating” evoke a large feature set. This proposal aims to fill a smaller gap.


  • It is simple.
  • Works with existing Go tooling and workflows.
  • Using Go 1.6 vendor support provides simple import paths
  • Generated code can be committed.
  • Annotations or extra runtime dependencies are not required.
  • Any Go package can potentially be used as a stencil.
  • Type specialisation information is present in the code and not in command line tool invocations.


  • Types in a package cannot be used in import paths in the same package.
  • Import paths containing pointer, array, map and channel types are not file-system friendly.
  • Types from generated code cannot be used as part of exported types or methods in other packages, due to how vendoring works.
  • Existing Go packages may not support simple type substitution. Type asserts can lead to compile errors when substituting a concrete type for an interface.
  • Zero values will need special handling, as they will differ by type.
  • Transitive stencilling may be needed in the case of package dependencies.

More design work is needed to address the cons.

@sridharv sridharv self-assigned this Jun 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant