October 28, 2015
On Tuesday, 27 October 2015 at 14:00:07 UTC, Martin Nowak wrote:
> Yikes, this is such an anti-pattern.
> https://github.com/rejectedsoftware/vibe.d/issues/634

Every time I use opDispatch, I add an if(name != "popFront") constraint, at least (unless it is supposed to be forwarding). It helps with this a lot and think everyone should do it.
October 28, 2015
On Wednesday, 28 October 2015 at 11:32:22 UTC, wobbles wrote:
> I just had a thought, I could check if dataName is in [__traits(allMembers ... )]. That would at least ensure I'm referencing something that exists.

If the body doesn't compile, the opDispatch acts as if it doesn't exist anyway. (this makes debugging it a bit of a pain but also means you don't strictly need constraints on bodies that don't work)
October 28, 2015
Am Tue, 27 Oct 2015 14:00:06 +0000
schrieb Martin Nowak <code@dawg.eu>:

> On Tuesday, 27 October 2015 at 13:14:36 UTC, wobbles wrote:
> >> How can `coordinates` member be known at compile-time when the input argument is a run-time string?
> >
> > I suspect through the opDispatch operator overload.
> >
> > http://dlang.org/operatoroverloading.html#dispatch
> 
> Yikes, this is such an anti-pattern. https://github.com/rejectedsoftware/vibe.d/issues/634

For my defense I can say that the JSON parser is not a range and thus less likely to be used in UFCS chains. It can be replaced with .singleKey!"coordinates"()

-- 
Marco

October 28, 2015
On Wednesday, 28 October 2015 at 13:56:27 UTC, Adam D. Ruppe wrote:
> On Tuesday, 27 October 2015 at 14:00:07 UTC, Martin Nowak wrote:
>> Yikes, this is such an anti-pattern.
>> https://github.com/rejectedsoftware/vibe.d/issues/634
>
> Every time I use opDispatch, I add an if(name != "popFront") constraint, at least (unless it is supposed to be forwarding). It helps with this a lot and think everyone should do it.

I would go even farther and say that one should never define opDispatch without a template constraint limiting which members can be dispatched on. It may be a bit radical but we could even go as far as outright deprecating unconstrained opDispatch.

//Okay
auto opDispatch(string member)()
if (member == "get" || isVectorSwizzle!member)
{
    //...
}

//Deprecated
auto opDispatch(string member)()
{
    //...
}
October 29, 2015
Marco, could you add your lib to review or do any steps that will help to include it's in Phobos? I think not only I interesting in good base JSON lib in base distribution.

October 29, 2015
On Thursday, 29 October 2015 at 12:11:54 UTC, Suliman wrote:
> Marco, could you add your lib to review or do any steps that will help to include it's in Phobos? I think not only I interesting in good base JSON lib in base distribution.

Marco's json library doesn't meet requirements for inclusion in Phobos and should stay separately in DUB registry.
Phobos needs much more generic library with support for streaming and ranges. I believe, that at the moment the best candidate is std.data.json by Sönke Ludwig.
November 16, 2015
What about data validation? Does it's fast complete full validation of data, and what about other parsers? Are they complete full validation?
April 25, 2017
you could check it out on http://jsontuneup.com for treeview your json object and wrong inside your json.
July 13, 2018
Any idea about the performance of this json parser? https://jsonformatter.org/json-parser ?
August 01, 2018
Am Fri, 13 Jul 2018 18:14:35 +0000
schrieb iris <iris.panabaker@gmail.com>:

> Any idea about the performance of this json parser? https://jsonformatter.org/json-parser ?

That one is implemented in client side JavaScript. I didn't measure it, but the closest match in Kostya's benchmark could be the Node JS entry that is an order of magnitude slower.

-- 
Marco