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
The slice library is rather large, which makes it painful to shadow and re-export everything with types.
I think perhaps a better design is to think of a slice as naming a set of locations, without owning pointers for those locations. Then, we can instantiate a predicate per location; this subsumes the current is_slice_small and updates_slice, and similar notions. Subslicing just changes the set of locations. If this turns out to be difficult or not useful, we can revert to essentially the untyped slice library but ported to have types.
This involves doing the following:
try out a new is_slice predicate that does not consume space but can be combined with a predicate per location
implement the current API using the new predicate
port all users of the untyped library to the typed version
rename is_slice_small to is_slice and is_slice to is_slice_append
use slice_cap separately where possible
The text was updated successfully, but these errors were encountered:
The slice library is rather large, which makes it painful to shadow and re-export everything with types.
I think perhaps a better design is to think of a slice as naming a set of locations, without owning pointers for those locations. Then, we can instantiate a predicate per location; this subsumes the current
is_slice_small
andupdates_slice
, and similar notions. Subslicing just changes the set of locations. If this turns out to be difficult or not useful, we can revert to essentially the untyped slice library but ported to have types.This involves doing the following:
is_slice
predicate that does not consume space but can be combined with a predicate per locationis_slice_small
tois_slice
andis_slice
tois_slice_append
slice_cap
separately where possibleThe text was updated successfully, but these errors were encountered: