You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
std/experimental was IMO a good idea (but was only used for lib/experimental/diff.nim) and allows 0-change migration for clients using the usual import/export or include trick in case it wants to migrate to std/diff once stabilized.
we should IMO do the same for fusion:
modules can mature in fusion/experimental, breaking changes are allowed there, and client code that decides to use those (directly or via transitive closure) should not complain about those.
#575 may be a better idea, avoid the problem raised
But now we created a situation where it's better to import experimental / module! Because that's the import that actually works with older versions of Nim! So client code becomes:
std/experimental was IMO a good idea (but was only used for lib/experimental/diff.nim) and allows 0-change migration for clients using the usual import/export or include trick in case it wants to migrate to std/diff once stabilized.
we should IMO do the same for fusion:
modules can mature in fusion/experimental, breaking changes are allowed there, and client code that decides to use those (directly or via transitive closure) should not complain about those.
links
nim-lang#16004 (comment)
The text was updated successfully, but these errors were encountered: