Ary Borenszweig

Then, how about we keep `JSON::Serializable` but the deserialization doesn't happen through a constructor? That way we don't have to use the `{{@type}}` hack, which also currently breaks other constructors...

@kostya [This commit](https://github.com/asterite/crystal-1/commit/99afac213915a7930d43ee9c4587c99e5e7e89ae) from [this branch](https://github.com/crystal-lang/crystal/compare/master...asterite:feature/refactor-from-json) has it working. As you can see: - the `included`, `inherited` and `dummy` parameter are all gone - I had to fix specs to...

@kostya Looks good! So simple :-) Well, everyone (cc @RX14 @straight-shoota @ysbaddaden) let me know if you think this is a good direction (using `from_json` instead of `new`), and I...

@RX14 I already said that `JSON::Serializable` would stay, it just wouldn't be a constructor. This is the **main** problem: - `JSON.mapping` was a macro that defined a constructor along with...

Yes, if a type defines an `initialize` method, then all `initialize` and `self.new` methods are not inherited. So this doesn't compile: ```crystal class Foo # Let's assume this is the...

I'm closing this. The state of the art for JSON/YAML looks good so far, even though there are some corner cases. Sorry for the noise.

Nah. I opened it, I can close it.

I don't think this is the way to go. The compiler rewrites a `select` into something else. Let the compiler allocate the static array with exactly the size needed, get...

Did you mean with a debug LLVM?

If you compile LLVM with debug mode on (assertions on) you'll find out the issue. How would a compiler build with debug info help in this case? LLVM is dying...