[Issue 12332] std.json API broken without notice

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Mar 9 11:49:58 PDT 2014


https://d.puremagic.com/issues/show_bug.cgi?id=12332


Adam D. Ruppe <destructionator at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |destructionator at gmail.com


--- Comment #2 from Adam D. Ruppe <destructionator at 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- at 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: -------


More information about the Digitalmars-d-bugs mailing list