Comment #2 by destructionator — 2014-03-09T11:49:53Z
Setting the type is something I was able to just comment out of my code to make it work on the new std.json.
My thought is setting type could be done with max compatibility by:
* if the set is binary compatible (casting it doesn't cause memory safety issues e.g. integer -> uinteger or string->string are OK, but string->array is out since that breaks the length and integer->string is out since that's a wild pointer) with what is already there, set it without changing contents.
* otherwise, reset the union to 0/null/type.init so it isn't used for un-@safe reinterpret casting while breaking minimum code.
These should handle both cases of
v.type = JSON_TYPE.STRING;
v.str = "foo";
and
v.integer = 10;
v.type = JSON_TYPE.UINTEGER;
Without sacrificing any safety.
another copy/paste from my experience on irc
One thing i had to refactor though was setting object fields. before i would set value.object["foo"] = bar;, whereas with the new one, i would make the object separately, then set it to the final thing all in one go (since otherwise value. object["foo"] tries to GET the object then call opIndex on it, which throws since the json type is null - that was a runtime break!)
But if the type setting works, this should work too. The problem I had was now setting type = object would fail to compile, thus causing v.obj to throw. If type=object works again, this might just work.
Comment #3 by github-bugzilla — 2014-03-10T08:23:35Z