eth: Add CoinID flags.

[JoeGruffins]

Add TxIDFlag and SwapFlag in order to specify that a coin ID represents
either a txid or a swap. IsTxIDCoinID and IsSwapCoinID package methods
are included so that callers can easily discern if they have the right
type of coin ID for the operation they are performing.

related to #1021

[JoeGruffins]

Using pointers to common.Address where possible. https://golang.org/doc/effective_go#arrays But more than that it bothered me to sorta use one or the other. Some of the ethclient methods from go-ethereum still take the value anyway.

[chappjc]

Using pointers to common.Address where possible. https://golang.org/doc/effective_go#arrays But more than that it bothered me to sorta use one or the other. Some of the ethclient methods from go-ethereum still take the value anyway.

Probably go-ethereum works with value args in places for the sweeter syntax (less & or new usage) and because pointer vs value often conveys intent to modify in the function, but +1 to passing pointers to avoid needless allocations.

If we have a common.Address as a struct field however, we should probably stick to values for sake of data locality, but that's a separate concern.

[JoeGruffins]

If we have a common.Address as a struct field however, we should probably stick to values for sake of data locality, but that's a separate concern.

Do you have some reading material about this? We often store pointers in structs, and in some cases it seems to just be better to use pointers to avoid unexpected bugs like #1124

[chappjc]

If we have a common.Address as a struct field however, we should probably stick to values for sake of data locality, but that's a separate concern.

Do you have some reading material about this? We often store pointers in structs, and in some cases it seems to just be better to use pointers to avoid unexpected bugs like #1124

In that issue embedding of a struct by value had a unique set of gotchas, especially when it contained a mutex. Although I'm really thinking about fields that are simple types rather than structs. For a field that is a simple type like an array, it makes sense to have the memory for all of the struct's data, including the array, be contiguous, from a single allocation. I suppose it depends on the specific case though.

decred/dcrd@20a8ccc, although I don't uniformly object to passing small arrays by value.

[JoeGruffins]

ty! Garbage collection is the main reason?

[chappjc]

ty! Garbage collection is the main reason?

GC, but also memory access efficiency. Accessing adjacent memory addresses will often benefit from low-level cache lines, thus speeding up successive access to multiple fields. Go's 64-bit alignment of structs memory and elimination of excess padding for small (<8 byte) fields makes this even more likely. Optimizing for this in this application is surely not critical, but it's a reason.

Also if we have a pointer to an array as a struct field, that's a separate heap allocated object. Might as well have the array just be a segment of the struct's memory. Of course there can be reasons why this isn't desirable, but in general I feel it's cleanest to just avoid the extra level of indirection, esp for small arrays like Hash or this common.Address type. However if we find ourselves doing lots of unnecessary copies or obtaining pointers to these fields, we might reconsider this approach.

[chappjc]

Looks good, just a few thoughts.