But perhaps I should stop gossiping on the list about this, and just code it up :)
So I do now have something that seems like a reasonable implementation of the _SAFE userdata semantic, and I've posted it, along with my old += patch, to the wiki.
But I'm not particularly satisfied with it how it turned out.
My current implementation basically works by adding the line "local _SAFE=_SAFE" to the start of any newly compiled chunk. And that has two unfortunate implications. One is that all main chunks now demand one more register than they used to, making them slightly larger. The other is that all main chunks now start with a table get, meaning that they're slower to execute. Whether or not this is likely to cause a problem depends very much on how people are using lua_load(). If lua_load() is only being used to compile script files, it's hard to imagine there being any significant issue.
But, lua is a language that includes its own interpreter. And if lua_load() is being used to compile large numbers of small, procedurally generated, 1 or 2 operation micro-functions; if, for example, you spend a lot of time doing things like:
setter = load("a="..b))
then the performance implications are going to start to become noticeable.
I've done some tests to try to get a sense for just how noticeable said overheads could become. Assuming a worst case usage scenario, like a script that does nothing but load and run thousands of tiny single value assignment chunks, I can concoct cases where the extra upvalues increase lua memory's memory footprint by as much as 20%, and place a similar penalty on runtime speeds. And that's not good.
So, it seems I've come full circle once again. Pretty though it may be -- the general semantic probably isn't worth the trouble :-P
I may still use it in my own personal projects -- that's a context where I can keep a careful eye on the overhead implications. But, I should probably change the patch linked on the wiki to back to the more restricted implementation.
-Sven
