std.jgrandson

[Sönke Ludwig via Digitalmars-d]

Am 04.08.2014 20:38, schrieb Jacob Carlborg:
> On 2014-08-04 16:55, Dicebot wrote:
>
>> That is exactly the problem - if `structToJson` won't be provided,
>> complaints are inevitable, it is too basic feature to wait for
>> std.serialization :(
>
> Hmm, yeah, that's a problem.

On the other hand, a simplistic solution will inevitably result in 
people needing more. And when at some point a serialization module is in 
Phobos, there will be duplicate functionality in the library.

>> I am pretty sure that this is not the only optimized serialization
>> approach out there that does not fit in a content-insensitive
>> primitive-based traversal scheme. And we won't Phobos stuff to be
>> blazingly fast which can lead to situation where new data module will
>> circumvent the std.serialization API to get more performance.
>
> I don't like the idea of having to reimplement serialization for each
> data type that can be generalized.
>

I think we could also simply keep the generic default recursive descent 
behavior, but allow serializers to customize the process using some kind 
of trait. This could even be added later in a backwards compatible 
fashion if necessary.

BTW, how is the progress for Orange w.r.t. to the conversion to a more 
template+allocation-less approach, is a new std proposal within the next 
DMD release cycle realistic?

I quite like most of how vibe.data.serialization turned out, but it 
can't do any alias detection/deduplication (and I have no concrete plans 
to add support for that), which is why I currently wouldn't consider it 
as a potential Phobos candidate.