On Sunday, 1 February 2015 at 07:56:53 UTC, data man wrote:
> On Sunday, 1 February 2015 at 06:08:35 UTC, Vladimir Panteleev wrote:
>> (Caveat: last one needs 5-ish compiler patches to work.)
>
> Which, please specify?

It should tell you nicely when you try to compile without them:

https://github.com/CyberShadow/ae/blob/master/utils/meta/caps.d

(pull #3345 is 3 commits)

On Sunday, 1 February 2015 at 10:07:42 UTC, Vladimir Panteleev wrote:
> On Sunday, 1 February 2015 at 07:56:53 UTC, data man wrote:
>> On Sunday, 1 February 2015 at 06:08:35 UTC, Vladimir Panteleev wrote:
>>> (Caveat: last one needs 5-ish compiler patches to work.)
>>
>> Which, please specify?
>
> It should tell you nicely when you try to compile without them:
>
> https://github.com/CyberShadow/ae/blob/master/utils/meta/caps.d
>
> (pull #3345 is 3 commits)

Alas, but...

void main()
{
    pragma(msg, is(typeof({ struct S { int i; } S s; __traits(child, s, S.i) = 0; })));
}

output "false"

On Sunday, 1 February 2015 at 11:12:11 UTC, data man wrote:
> Alas, but...
>
> void main()
> {
>     pragma(msg, is(typeof({ struct S { int i; } S s; __traits(child, s, S.i) = 0; })));
> }
>
> output "false"

By "5-ish compiler patches" I meant patches that are not in the official compiler. I would be very, very surprised if it worked out of the box for you.

On Sunday, 1 February 2015 at 13:43:19 UTC, Vladimir Panteleev wrote:
> By "5-ish compiler patches" I meant patches that are not in the official compiler. I would be very, very surprised if it worked out of the box for you.

Yes, I understand.
You do not plan to modify their for current state of the D repository?

On Sunday, 1 February 2015 at 14:10:58 UTC, data man wrote:
> On Sunday, 1 February 2015 at 13:43:19 UTC, Vladimir Panteleev wrote:
>> By "5-ish compiler patches" I meant patches that are not in the official compiler. I would be very, very surprised if it worked out of the box for you.
>
> Yes, I understand.
> You do not plan to modify their for current state of the D repository?

It would be a massive rewrite, and since I won't have the compiler features I want, the code will be twice as bigger/uglier.

I'd rather wait until I have time to properly formulate and propose my changes as language improvements. It's a big project and an uphill battle, since it's fairly niche.

On Sunday, 1 February 2015 at 06:08:35 UTC, Vladimir Panteleev wrote:
> On Thursday, 29 January 2015 at 20:04:51 UTC, Pierre Krafft wrote:
>> It's fun to see that there are so many different solutions to working with JSON in D. jsvar seems to be for keeping your variables in JavaScript-land, something I think is a bad idea in most cases. The idea of painlessjson is to convert to native D as fast as possible. The goal is to get something like https://github.com/FasterXML/jackson for D.
>> We are still looking for input on how inheritance and constructors should work.
>
> This is nothing new, I believe Vibe.d has a similar JSON (de)serializer.
>
> Here's my own: https://github.com/CyberShadow/ae/blob/master/utils/json.d
>
> Too slow? Try this one instead:
>
> https://github.com/CyberShadow/ae/blob/master/utils/serialization/json.d
>
> (Caveat: last one needs 5-ish compiler patches to work.)

You are right. My intention is not to make it seem like this is new or revolutionary. The intention is to get some input on the work and hopefully provide a solution that in the end will be well documented, easy to find, and easy to integrate with. I don't know why I didn't find the one in vibe.d but it's still bundled with a lot else and uses it's own JSON implementation.

Painlessjon was the only library I could find on Github when searching for JSON that I could get working. Almost every library provided their own instead of using std.json.If std.json is bad it should be improved to help everyone using it.

The D community need to be better at putting their work on DUB and to separate their libraries more. I know that there are many tools out there that is not fully utilized because it's so hard to find them.

I will continue working on painlessjson and will take a look on the implementations I have now found and try to take the best from them. I have already seen some things in your code that I can make use of.