open-consul/types
Mike Morris 78a008daf6
types: add types/tls.go for strongly-typed TLS versions and cipher suites (#11645)
types: add TLS constants

types: distinguish between human and Envoy serialization for TLSVersion constants

types: add DeprecatedAgentTLSVersions for backwards compatibility

types: add methods for printing TLSVersion as strings

types: add TLSVersionInvalid error value

types: add a basic test for TLSVersion comparison

types: add TLS cihper suite mapping using IANA constant names and values

types: adding ConsulAutoConfigTLSVersionStrings

changelog: add entry for TLSVersion and TLSCipherSuite types

types: initialize TLSVerison constants starting at zero

types: remove TLSVersionInvalid < 0 test

types: update note for ConsulAutoConfigTLSVersionStrings

types: programmatically invert TLSCipherSuites for HumanTLSCipherSuiteStrings lookup map

Co-authored-by: Dan Upton <daniel@floppy.co>

types: add test for TLSVersion zero-value

types: remove unused EnvoyTLSVersionStrings

types: implement MarshalJSON for TLSVersion

types: implement TLSVersionUnspecified as zero value

types: delegate TLS.MarshalJSON to json.Marshal, use ConsulConfigTLSVersionStrings as default String() values

Co-authored-by: Dan Upton <daniel@floppy.co>
2021-12-03 20:17:55 -05:00
..
README.md
area.go
checks.go
node_id.go
tls.go
tls_test.go

README.md

Consul types Package

The Go language has a strong type system built into the language. The types package corrals named types into a single package that is terminal in go's import graph. The types package should not have any downstream dependencies. Each subsystem that defines its own set of types exists in its own file, but all types are defined in the same package.

Why

Everything should be made as simple as possible, but not simpler.

string is a useful container and underlying type for identifiers, however the string type is effectively opaque to the compiler in terms of how a given string is intended to be used. For instance, there is nothing preventing the following from happening:

// `map` of Widgets, looked up by ID
var widgetLookup map[string]*Widget
// ...
var widgetID string = "widgetID"
w, found := widgetLookup[widgetID]

// Bad!
var widgetName string = "name of widget"
w, found := widgetLookup[widgetName]

but this class of problem is entirely preventable:

type WidgetID string
var widgetLookup map[WidgetID]*Widget
var widgetName

TL;DR: intentions and idioms aren't statically checked by compilers. The types package uses Go's strong type system to prevent this class of bug.