`borsh::io::Error::new` diverges from `std::io::Error`

[kayabaNerve]

borsh-rs/borsh/src/nostd_io.rs

Line 229 in a34f324

pub fn new<T: Into<String>>(kind: ErrorKind, error: T) -> Error {

https://docs.rs/borsh/latest/borsh/io/struct.Error.html#method.new

Into<String> vs Into<Box<dyn Error + Send + Sync>>.

I don't see a reason why it should be so specialized. This is technically a breaking change for the no-std API, as a type may impl Into<String> but not Into<Box<dyn Error>>, but I'd argue it as a bug fix.

I open this issue not for the hell of it, but because I did run into this while mapping borsh's no-std io to some work of my own.

[dj8yfo]

@kayabaNerve i guess i did notice this discrepancy too when moving the module back and forth.
it's the same in https://doc.rust-lang.org/1.67.0/std/io/struct.Error.html (and looks like everywhere below too, i tool a look at 1.21).
agree that it should be put to a bugfix category

i'll submit (or will accept) a pr with this change Into<String> => Into<Box<dyn Error + Send + Sync>>

[dj8yfo]

I don't see a reason why it should be so specialized.

yes, ok, the reason is that https://doc.rust-lang.org/std/error/trait.Error.html was never transferred to borsh::nostd_io ,
probably for the sake of simplicity.

If one starts to transfer that, then he/she would become unsure of when to stop.

@kayabaNerve you'd have to share the results of your experiments, in which way specifically borsh is blocking you.
Maybe we can work out a way without (over?) complicating borsh.
As the doc string suggests, the implementation was minimal enough to support

/// let custom_error = Error::new(ErrorKind::Other, "oh no!");

thas is all, which is the only thing borsh needed to stay polymorphic over no_/std::io in order to be able to compile and run

https://doc.rust-lang.org/std/string/struct.String.html#impl-From%3CString%3E-for-Box%3Cdyn+Error%3E

[dj8yfo]

this thingy looks relatively actively used, especially recently, https://crates.io/crates/no_std_io
borsh::nostd_io can be tried to be duct-taped to this.

but then it doesn't look too officially and actively maintained

[kayabaNerve]

There is now core::error::Error if the MSRV bump is acceptable. There doesn't have to be a reproduction of it.

Otherwise, I'd advocate a trait Error: Debug {} with a default impl as a better shim if the MSRV bump isn't acceptable. All instances of the actual Error trait, as necessary to satisfy it on std, will satisfy that. The exact depth it should further model I don't immediately comment on.

[dj8yfo]

The msrv bump feels a little too high, we could try doing https://crates.io/crates/rustversion #[rustversion(since(...))] and #[rustversion(before(...))] instead .

[frol]

Just a note: Rust 1.81 is the last version that compiles wasm files compatible with nearcore out of the box. The newer Rust versions include new Wasm features that are not supported by Wasm runtime in nearcore.

What worries me much more is the breaking change. While I don't like misalignment, the breaking change + too recent MSRV make me really uneasy, and I would strongly consider keeping it as is until there is a real demand for this to be fixed or we batch it with other breaking changes

[kayabaNerve]

@frol Isn't that why wasm32v1-none, tier 2 since 1.84, explicitly exists?

[frol]

@kayabaNerve wasm32v1-none does not have std by default and as such require nightly compiler, which is not what we want to recommend users to use to build their contracts.

[kayabaNerve]

This wasm32v1-none target exists as an alternative option that works on stable Rust toolchains, without rebuilding the stdlib.

From the very link you cited. The fact wasm targets doesn't support std inherently is a limitation of WASM being a machine specification, not a full operating system, and not a limitation of the specific target I noted.

[frol]

@kayabaNerve I certanly understand that, but I refer to developer experience that we don't want to degrade for near-sdk-rs users, which is why we don't want to switch to recommending wasm32v1-none and still have to use wasm32-unknown-unknown, and as such support for Rust 1.81 is helpful since 1.82 introduced new default features to wasm32-unknown-unknown target that are not yet supported by nearcore