On Wed, 2 Sept 2026 at 17:32, Japin Li <[email protected]> wrote: > > On Wed, 02 Sep 2026 at 13:36, Matthias van de Meent > <[email protected]> wrote: > > Hi, > > > > I'd like to track the size of a dlist for data structure validation > > purposes[^0]. Normally, one would use a dclist, as this tracks a > > count of list elements contained therein, but because this code would > > not be called in most normal production builds using a dclist would > > waste precious memory. > > Manually tracking the length is possible, but tedious, and a local > > wrapper around the used dclist/dlist APIs (with different > > implementations conditioned with #ifdefs to use the right types) would > > also be a significant amount of effort, that'd be duplicated every > > time . > > > > Attached is a patch that adds glist_* macros, which wrap several > > dlist/dclist_* APIs, so that developers can use dlist/dclist > > selectively in different environments, without significant visual > > overhead in the code. I'm planning to use this in the Proxy memory > > contexts over at [1]. > > > > I've considered also adding slist_* to the macros, but I've never > > needed selective slist vs dlist/dclist before, so I ignored that list > > type for now. > > > > +1 for this idea. > > Should we adopt the new glist interface in the existing code to better > showcase its intended use?
Did you have a place in mind where we have dlist and dclist in use to track the same information in different build configurations? I don't like churning code for the sake of new APIs, especially when those new APIs are not strictly better than the current ones. Note that I add glist to solve ergonomics issues when you want to handle both types of lists. It's not meant to be used as default API to fields that are always of a dlist type, or always of a dclist type, even if it could be used like that. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
