Support `no_std` usage

[Pzixel]

I'm working on no_std library and I encountered a problem with serde that it doesn't work when I compile for the target (see openethereum/pwasm-abi#54 ). After some investigation I found that it seems evildoer is this crate. So I tried to replace serde in dependencies with:

serde = { version = "1", default-features = false }

It almost compiled, however I've got several erros. One of them is was

error[E0407]: method `visit_string` is not a member of trait `Visitor`
  --> C:\Users\Alex\Documents\Repo\json\src\value\de.rs:76:13
   |
76 | /             fn visit_string<E>(self, value: String) -> Result<Value, E> {
77 | |                 Ok(Value::String(value))
78 | |             }
   | |_____________^ not a member of trait `Visitor`

It's because Visitor trait has cfg attribute:

#[cfg(any(feature = "std", feature = "alloc"))]
fn visit_string<E>(self, value: String) -> Result<Value, E>;

When implementation - doesn't.

It seems that the crate was never tested against no_std environments (sorry if I'm wrong).

I could try to fix all issues myself and create a PR, but I'm not sure that I'm doing the right thing or don't.

Please, see referenced issue if you want to know why I came here with this proposal.

[dtolnay]

Please use serde-json-core if you need a no-std JSON library.

[Pzixel]

Unfortunately, it doesn't work with structs so this is a no-way. I'l try it out, however, there are several considerations.

It seems pretty easy to solve these three issues to make it non-std compatible. It probably won't be a good way to run it on devices with limited CPU/memory capabilities, but there still plenty of powerful devices that require no_std target.

So either std feature should be removed from the crate (to not confuse people that it supports some kind of no_std) or adopt no_std completely. I think the latter is the better alternative.

[dtolnay]

I am closing the issue because I don't intend to bring no-std support into serde_json as discussed previously in #362.

std feature should be removed from the crate (to not confuse people that it supports some kind of no_std)

I'm afraid I don't understand what std feature this suggestion refers to. The serde crate has a std feature because its dependency on the standard library is optional. Serde data formats without a standard library dependency exist, including the mentioned serde-json-core and a couple others. The serde_json crate does not have a std feature because its dependency on the standard library is not optional.

[Pzixel]

@dtolnay I have several considerations

1. This crate doesn't work with alloc types such as String or Vec. How can I serialize something into JSON if it doesn't support strings?
2. It look a bit abandoned, this crate doesn't even exist on crates.io (latest version is 0.0.1, when actual is 0.1.0).
3. It look pretty straightforward to add no_std in the crate. This restriction may be relaxed later, if required.
4. You alredy have cfgs like

#[cfg(any(feature = "std", feature = "alloc"))]

If you don't want to support no_std you don't need to cfg based on these features.

But as I said, it hasyou have to fix only 3 places via cfgd or slight rewriting to make it work in no_std scenarios.

---

Author explicitely says:

This is explicitly out of scope

• Anything that involves dynamic memory allocation
  • Like the dynamic Value type

So if I have struct with String field then I have no crate to serialize it. Sounds weird.

[Pzixel]

I'm currently in the situration where I need to serialize some Vec's and Stirngs's into json. What crate should I use and how?

---

In a nutshell: I'm writing a library for wasm. So I need to run without standard library (no_std) and I clearly have to serialize Strings/Vecs/etc... But I currently just can't. serde_json doesn't work with no_std, and serde_json_core doesn't work with alloc::* types.

[Pzixel]

I crated a question about it, if you are insterested: https://users.rust-lang.org/t/how-to-serialize-json-in-no-std-library/18915

[dtolnay]

I would be willing to consider a PR that adds a std feature on by default, and exposes the same or a subset of the current API of serde_json by using the alloc crate in no_std mode. Let's track this in #362.