I would suggests that the requests, if you pursue that idea, “should merely be descriptive.”   If the manner by which they are (presently...) implemented is by very-clever use of eval, then so be it ... but don’t scatter that implementation detail throughout all of the client code.   One day, you might decide that this approach is not so Tom Swifty after all, and if this be so, it should be easily and (ahem...) “Swiftly” replaceable without impacting much source-code that is hither, tither and yon.

Yes, I agree. In practice, I would create a package with a trivial new, and insert, update, delete and fetch methods as a generic interface which could be replaced by alternative solutions at a later time transparently to the caller(s).

One world, one people

I would create a package with a trivial new, and insert, update, delete and fetch methods as a generic interface

And all you would have done is replicate the tie mechanism with slightly different method names and calling syntax. It would be no more efficient of time nor space. No easier to use or maintain.

And it would need to address all the same locking and sharing, creation and destruction problems that thread::shared variables already address.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.