https://d.puremagic.com/issues/show_bug.cgi?id=12332
Adam D. Ruppe <destructiona...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |destructiona...@gmail.com
--- Comment #2 from Adam D. Ruppe <destructiona...@gmail.com> 2014-03-09
11:49:53 PDT ---
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.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
