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
It holds that type_eq(t1, t2, ns) implies base_type_eq(t1, t2, ns), but the converse isn't necessarily true (if expansion of symbol types isn't consistent between t1 and t2). This distinction, however, is subtle and only comes with a some (not measured) performance benefit. Maintaining two functions doing almost the same is painful and confusing.
In the medium term, neither type_eq nor base_type_eq should be necessary as tag types ought to enable use of operator== as the one and only equality comparison over types.
The text was updated successfully, but these errors were encountered:
It holds that
type_eq(t1, t2, ns)
impliesbase_type_eq(t1, t2, ns)
, but the converse isn't necessarily true (if expansion of symbol types isn't consistent betweent1
andt2
). This distinction, however, is subtle and only comes with a some (not measured) performance benefit. Maintaining two functions doing almost the same is painful and confusing.In the medium term, neither
type_eq
norbase_type_eq
should be necessary as tag types ought to enable use ofoperator==
as the one and only equality comparison over types.The text was updated successfully, but these errors were encountered: