On Thu, May 22, 2025 at 01:50:18AM -0700, Karthik Nayak wrote: > > If we store and return a "void *" pointer as we do now, but accept a > > const pointer via strmap_put(), then we're casting away potentially > > important const-ness without the caller even seeing it. I think it's > > safer for the client to do the cast explicitly (since they are the ones > > who know how they plan to use it). > > > > But isn't that the case now anyways? We always lose the const-ness since > we only accept a 'void *'. But by only changing 'strmap_put()' to accept > a 'const void *', but storing and returning a 'void *'. We simply modify > the current construct to also say that any data received is not > modified. But I do see your point, we'll have to cast there anyways and > might as well do it on the client side. Right, there is no winning here in the type system. But by pushing the cast onto the calling side, it is more visible and closer to the code that knows how the result will be used. > > I don't think we can really represent what we want in C's type system. > > But if we wanted a safe(r) interface that didn't involve type-casting, > > we might be able to do something like: > [...] > Agreed, and then there is additional load to ensure users will use > 'strmap_put()' and 'strmap_put_const()' as required and simply not cast > away. That part I'm not too worried about, since casts are easy-ish to catch and flag in reviews. But I'm not sure if it's materially making the world a better place to have the extra complexity. -Peff
