daxpedda

> > is an acceptable breaking change > > Probably not, especially considering the widely use of crates such as `ring` and `zstd-sys` that require compiled C code. Well, this...

While this is otherwise non-actionable by us, we should at least document this somewhere. We could actually introduce a proper error message here: we could encode which target features are...

> I found another issue: under Rust 1.82, `cfg!(target_features = "reference-types")` is false, but the final product had the `reference-types` target_feature. So v1.82 is where reference-types is enabled by default....

> [..], I'd just like to have a test but we can revert asap anyway. I think the test is just running it with Rust v1.82. > Not being able...

> > I think in the future we should be more careful in Rust to stabilize target features when they are enabled by default and not afterwards. > > Do...

It is fine, was my bad. Please refrain from explicit pinging for just a regular answer. Thanks.

> @daxpedda it requires us to write wrappers around all types, and then add send and sync to all those types. See e.g. https://github.com/search?q=repo%3Acloudflare%2Fworkers-rs%20unsafe%20impl%20Sync&type=code. You could instead use `struct SendSyncWrapper(T);`....

> > You could instead use struct SendSyncWrapper(T);. A single wrapper that would work for all of them. > > What I'm hearing here is alternatives, what I don't hear...

> If the feature is not recommended in documentation, clearly marked as unsafe, and requires a compiler flag to activate, then it seems to me that libraries simply won't rely...

> > This might be a general theme for platforms, so let me know. > > Yes, as the platform we control the toolchain for the most part, and use...