@@ -51,7 +51,7 @@ with the overall design. Here is some relevant guidance.
51
51
If you want to handle multiple invariants, chain the weakens/strengthens.
52
52
You may do this by nesting 'SW' uses, but you will then have to write your own
53
53
instances, as the generics cannot handle such chaining. Alternatively, you may
54
- use 'SWChain '. This will add another newtype layer to the strong representation,
54
+ use 'WeakenN '. This will add another newtype layer to the strong representation,
55
55
but the generics are happy with it.
56
56
57
57
Some types may not have any invariants which may be usefully relaxed e.g.
@@ -67,18 +67,4 @@ necessarily what you want - indeed, it appears this sort of design would require
67
67
a @'Weak' a = a, weaken = id@ overlapping instance, which I do not want. On the
68
68
other hand, @[a]@ /does/ weaken to @['Weak' a]@, because there are no invariants
69
69
present to remove, so decomposing is all the user could hope to do.
70
-
71
- Another problem is coercible newtypes such as @Tagged@ from the @tagged@
72
- package. These have no invariants for us to weaken, so one's knee-jerk reaction
73
- might be to weaken the inner type. But what if the user doesn't want to weaken
74
- that inner type? They might be happy with using 'Data.Word.Word' instead of
75
- 'Numeric.Natural.Natural', for example.
76
-
77
- strongweak provides a special type 'Coercibly' which permits precisely defining
78
- how to weaken a newtype/pair of coercible types. For this reason, zero-invariant
79
- coercible newtypes are excluded from the strongweak ecosystem (e.g.
80
- 'Data.Functor.Identity.Identity', 'Data.Functor.Const.Const', @Tagged@).
81
-
82
- If your newtype puts the wrapped type as the final type variable, use
83
- 'Coercibly1' for a considerably simpler invocation.
84
70
-}
0 commit comments