Strongly typed UTXOs

[JoshOrndorff]

This is an attempt to move toward Andrew's original design for Tuxedo piece data as described on #1 and agreed upon in #1 (comment)

AFAIR we always thought this was a good idea and just never got around to it yet. This is my first attempt and it got stopped by a few other chores.

[muraca]

I really really like this approach. I feel that things are simpler and more intuitive.

[JoshOrndorff]

Here's a problem I"m having conceptually. When we aggregate this all together, we get an OuterUtxoData enum. It has a variant for each inner constraint checker. So it might look something like this:

pub enum OuterUtxoData {
  Kitties(KittiesUtxoData),
  Money(MoneyUtxoData),
  Dex(DexUtxoData),
}

So now there are two "paths" to the coin type. There is to original OuterUtxoData::Money(Coin) path and also the new OuterUtxoData::Dex(<T as ...>::Coin>.

[JoshOrndorff]

We may be able to solve the type aggregation problem by having the aggregation macros create something like this as output.

pub enum ChemistryData {
  Hydrogen,
  Helium,
  // --snip--
}

pub enum MoneyData {
  Coin(Coin),
  CertificateOfPreviouslyBurntCoin(Coin),
}

pub enum DexData {
  Order(OrderData),
  // Here is the challenging part. This needs to be the
  // same exact type that we have in the money piece
  Coin(Coin),
}

The key observation is that types that are shared among multiple pieces should be declared at the higher level of the aggregation tree. And similarly they should be represented in the aggregate type tree at that level.

/// This outer utxodata type is created by the aggregation macros.
pub enum OuterUtxoData {
  // First there is a variant for each piece. This is the normal straight-forward
  // aggregation stuff.
  Chemistry(ChemistryData),
  Money(MoneyData),
  Dex(DexData),

  // Then there is a variant for any types that had to be shared at this level
  // TBD how and whether the existing constraint checker macro can be smart enough
  // to determine which types need to come here automagically.
  //
  // Maybe a better approach is for the developer to separately aggregate the types with a third macro...
  Coin(Coin),
}

// The macro also writes these impls. The first several are trivial.
impl TryFrom<OuterUtxoData> for ChemistryData { ... }
impl TryFrom<OuterUtxoData> for MoneyData { ... }
impl TryFrom<OuterUtxoData> for DexData { ... }

As I wrote this and thought more, I realized that when aggregating some constraint checkers into a bigger one, it really does take some additional work to express which types need to be shared among pieces. Still some design work to be done here.