E.S. Quinn

Given that Lua's and D's type systems don't overlap all that well. I'm going to personally vote for manual overload resolution, at least by default.

...Oh, Duh! Sorry, I managed to completely overlook that. That's exactly what I want--Throwing it into my production code is triggering an ICE, but that's a problem to file with...

Specifically, it seems like having a function that returns a LuaVariableReturn!(LuaObject[]), calling it from D code, and discarding the return value completely triggers an ICE, at least on DMD 2.065/Win32....

I understand; That seems a little less-than-ideal for a program with multiple LuaStates, though (I'm using a couple different ones for sandboxing purposes). Is there any way we could get...

That's fair enough; Though this might be another situation where a UDA would be appropriate; if, for example, a function's first parameter was a LuaState, and it was marked with...

Oh, darn :/ and it doesn't throw errors on attaching it to a type declaration either. In that case there's probably not a good solution to this. :/ I really...

Because the program has multiple LuaStates, and the code that needs to create a LuaObject can be called from any of them; The only way I can imagine making it...

Aw, darn. :( I'm sorry to hear that. Though we'll likely have to store something anyway--I've had problems in my code on occasion with ranges that don't like being stored...

I confess I've been a bit focused on some collision-related code and haven't dug around in anything DSFML-touching for a while, so no. ^^; I can try looking in that...

Oh, I think I figured out the problem. I was creating strings inside a Destructor, which is apparently undefined behavior. It worked sometimes but barfed horribly at other times!