boa/boa_macros_tests/Cargo.toml

[package]
name = "boa_macros_tests"
description = "Testing crate for boa_macros"
keywords = ["javascript", "ECMASCript", "compiler", "tester"]
publish = false
version.workspace = true
edition.workspace = true
authors.workspace = true
license.workspace = true
repository.workspace = true
rust-version.workspace = true

[dev-dependencies]
trybuild = "1.0.81"
boa_macros.workspace = true
boa_engine.workspace = true
Initial version of a JS -> Rust conversion trait. (#2276) This Pull Request closes #1975. It's still a work in progress, but tries to go in that direction. It changes the following: - Adds a new `TryFromJs` trait, that can be derived using a new `boa_derive` crate. - Adds a new `try_js_into()` function that, similarly to the standard library `TryInto` trait Things to think about: - Should the `boa_derive` crate be re-exported in `boa_engine` using a `derive` feature, similar to how it's done in `serde`? - The current implementation only converts perfectly valid values. So, if we try to convert a big integer into an `i8`, or any floating point number to an `f32`. So, you cannot derive `TryFromJs` for structures that contain an `f32` for example (you can still manually implement the trait, though, and decide in favour of a loss of precision). Should we also provide some traits for transparent loss of precision? - Currently, you cannot convert between types, so if the JS struct has an integer, you cannot cast it to a boolean, for example. Should we provide a `TryConvertJs` trait, for example to force conversions? - Currently we only have basic types and object conversions. Should add `Array` to `Vec` conversion, for example, right? Should we also add `TypedArray` conversions? What about `Map` and `Set`? Does this step over the fine grained APIs that we were creating? Note that this still requires a bunch of documentation, tests, and validation from the dev team and from the users that requested this feature. I'm particularly interested in @lastmjs's thoughts on this API. I already added an usage example in `boa_examples/src/bin/derive.rs`. Co-authored-by: jedel1043 <jedel0124@gmail.com> 2 years ago			`[package]`
			`name = "boa_macros_tests"`
			`description = "Testing crate for boa_macros"`
			`keywords = ["javascript", "ECMASCript", "compiler", "tester"]`
			`publish = false`
			`version.workspace = true`
			`edition.workspace = true`
			`authors.workspace = true`
			`license.workspace = true`
			`repository.workspace = true`
			`rust-version.workspace = true`

			`[dev-dependencies]`
Changelog17 (#3101) * v0.17.0 changelog * Added latest changes, updated dependencies --------- Co-authored-by: Iban Eguia Moraza <razican@protonmail.ch> 1 year ago			`trybuild = "1.0.81"`
Initial version of a JS -> Rust conversion trait. (#2276) This Pull Request closes #1975. It's still a work in progress, but tries to go in that direction. It changes the following: - Adds a new `TryFromJs` trait, that can be derived using a new `boa_derive` crate. - Adds a new `try_js_into()` function that, similarly to the standard library `TryInto` trait Things to think about: - Should the `boa_derive` crate be re-exported in `boa_engine` using a `derive` feature, similar to how it's done in `serde`? - The current implementation only converts perfectly valid values. So, if we try to convert a big integer into an `i8`, or any floating point number to an `f32`. So, you cannot derive `TryFromJs` for structures that contain an `f32` for example (you can still manually implement the trait, though, and decide in favour of a loss of precision). Should we also provide some traits for transparent loss of precision? - Currently, you cannot convert between types, so if the JS struct has an integer, you cannot cast it to a boolean, for example. Should we provide a `TryConvertJs` trait, for example to force conversions? - Currently we only have basic types and object conversions. Should add `Array` to `Vec` conversion, for example, right? Should we also add `TypedArray` conversions? What about `Map` and `Set`? Does this step over the fine grained APIs that we were creating? Note that this still requires a bunch of documentation, tests, and validation from the dev team and from the users that requested this feature. I'm particularly interested in @lastmjs's thoughts on this API. I already added an usage example in `boa_examples/src/bin/derive.rs`. Co-authored-by: jedel1043 <jedel0124@gmail.com> 2 years ago			`boa_macros.workspace = true`
			`boa_engine.workspace = true`