My only fear is allocatable deferred length characters. But, it would be great to use polymorphism.

First cut is done! Seems to pass all the unit tests.

@zbeekman In your copious free time :), if you have any comments I would be interested to hear them. I'm going to wait a while to merge this in until I look over it some more.

Note: With these changes, I think I will revisit #38. For some use cases, it would be way more efficient to just store arrays as normal fortran arrays rather than as linked lists. Example:

    type,extends(json_data) :: json_real_vec1d_type
        !! a `json_real` 1d array
        real(RK),dimension(:),allocatable :: value
    end type json_real_vec1d_type

I'd need to think through the implications of this for the parser, etc...

For people using (abusing?) JSON-Fortran to collect and access large array data sets (but don't care about being able to manipulate the JSON structure) it would be a massive improvement I think.

I will be extending JSON-Fortran this month (starting today/tomorrow and next week) to have native support for ragged-edge matrices. So long as arrays of arrays are still handled well (I don't see why they wouldn't be the case) then this should be fine.

As previously mentioned, I'm a bit concerned about allocatable character scalars (and how will you treat arrays of strings?) because they seem to trigger strange bugs with GFortran and (to a lesser extend not) Intel. The project I am working on requires Intel 18 (windows & linux) and GFortran 8.3 (macOS, Linux). So long as complicated cases work with these toolchains (with and w/o optimization enabled), I'd be happy to see this implemented.

Awesome! Yes, I think it would work for arrays of arrays if done right.

Note: I added (#414) more versions of gfortran to the travis tests. So we can test all the recent versions. Note that I still have many compiler directives in the code to workaround various gfortran bugs for allocatable chars. Probably now that I'm testing all the versions, I can see about only applying the workarounds to the versions that still have the bug. Probably that would speed it up a bit too (#415).