Tracking issue for nightly requirement?

[nuke-web3]

https://book.leptos.dev/getting_started/index.html#hello-world-getting-set-up-for-leptos-csr-development has a reference to needing nightly, is there a rust-lang tracking issue open that could be referenced there? I for one would like to subscribe to it and others may want to learn more specifics that are blocking using all of leptos with stable.

[gbj]

You can use all of Leptos with stable. The nightly feature enables the function-call syntax for signals, which is used in the book because it helps develop the mental model (reactivity = functions) and because I think it's much more convenient in many cases.

If you want to use Leptos with stable, you just need to mentally prepare to swap in foo.get() for foo(), and on occasion to turn a plain foo into move || foo.get() if something like a component prop requires a function.

The nightly traits used are unboxed_closures and fn_traits. auto_traits and negative_impls are used for some parts of the API in the router crate and elsewhere.

[nuke-web3]

Thanks for the details!
I have yet to actually dig into building with Leptos to see how impactful that trade off is, seems reasonable to try stable and find out.

For others curious these would be helpful to give context on the reasons nightly is needed (Perhaps adding a note in the book with these links would be useful too):

• https://doc.rust-lang.org/beta/unstable-book/language-features/unboxed-closures.html
• https://doc.rust-lang.org/beta/unstable-book/library-features/fn-traits.html
• https://doc.rust-lang.org/beta/unstable-book/language-features/auto-traits.html
• https://doc.rust-lang.org/beta/unstable-book/language-features/negative-impls.html

Seems that based on this, it isn't likely all those features will hit stable anytime soon. So nightly will be required for the foreseeable future. yea?