You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not too happy with the `Castable` constraint, and I already have ideas for how to get rid of it. But maybe we should do it in a follow-up to this main body of UTXO-HD work.
The idea is to not parameterise LedgerTables by the ledger state type l but by the block type blk. Castable is currently capturing the fact that key/value types are the same regardless of whether l ~ LedgerState blk, or l ~ ExtLedgerState blk, or l ~ Ticked (LedgerState blk). This is true for all block types:
The reason I did not implement this change initially is that I trouble fitting this into the code, because some parts are blissfully unaware of the fact that a type parameter l, representing (ticked/extended) ledger states, always has a blk type parameter in practice. It would be a largish refactoring to make code aware of the blk parameter where necessary.
The idea is to not parameterise
LedgerTables
by the ledger state typel
but by the block typeblk
.Castable
is currently capturing the fact that key/value types are the same regardless of whetherl ~ LedgerState blk
, orl ~ ExtLedgerState blk
, orl ~ Ticked (LedgerState blk)
. This is true for all block types:The reason I did not implement this change initially is that I trouble fitting this into the code, because some parts are blissfully unaware of the fact that a type parameter
l
, representing (ticked/extended) ledger states, always has ablk
type parameter in practice. It would be a largish refactoring to make code aware of theblk
parameter where necessary.Originally posted by @jorisdral in #1267 (comment)
The text was updated successfully, but these errors were encountered: