Commit eecc16d
committed
Remove non_exhaustive from Network
Issue rust-bitcoin#2225 is long and has many valid opposing opinions. The main
argument for having non_exhaustive is that it helps future proof the
ecosystem at the cost of pain now. The main argument against having
non_exhaustive is why have pain now when adding a network is so rare
that having pain then is ok.
At the end of the thread Andrew posts:
> I continue to think we should have an exhaustive enum, with a bunch of
> documentation about how to use it properly. I am warming up to the
> "don't have an enum, just have rules for defining your own" but I think
> this would be needless work for people who just want to grab an
> off-the-shelf set of networks or people who want to make their own enum
> but want to see an example of how to do it first.
In order to make some forward progress lets remove the `non_exhaustive`
now and backport this change to 0.32, 0.31, an 0.30.
Later we can add, and release in 0.33, whatever forward protection /
libapocalyse protection we want to add.
This removes the pain now and gives us a path to prevent future pain -
that should keep all parties happy.1 parent e376e90 commit eecc16d
1 file changed
+9
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
61 | 61 | | |
62 | 62 | | |
63 | 63 | | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
64 | 73 | | |
65 | 74 | | |
66 | 75 | | |
67 | 76 | | |
68 | | - | |
69 | 77 | | |
70 | 78 | | |
71 | 79 | | |
| |||
0 commit comments