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
As argued by @KristofferC ion #811 (comment) (and I tend to agree), Compat should not commit type piracy by adding methods to Base functions for Base types, but rather define distinct functions of the same name, so that usage needs to be explicit opt-in (by qualification or explicitly named using).
This is different from how we used to do it, by I think it's worthwhile.
If we agree to do it this way, we should start by applying this rule to any new features. I'm not sure we should also go to the trouble of deprecating the old style in favor of the new style for existing features. Anyway, this likely warrants some discussion before setting anything in motion.
The text was updated successfully, but these errors were encountered:
ifVERSION<v"1.9.0-DEV.461"VersionNumber(args...) = Base.VersionNumber(args...)
VersionNumber(v::VersionNumber) = v
elseconst VersionNumber = Base.VersionNumber
end
And users then do Compat.VersionNumber(x) whenever x is (or at least could be) a VersionNumber. All good. But then, eventually, we drop support for Julia prior to 1.10 in Compat v5.0.0, say. Then what? Keep const VersionNumber = Base.VersionNumber indefinitely? Deprecate it to Base.VersionNumber and remove it in v6? Keep it for v5, deprecate in v6, remove in v7?
We would like people to declare compatibility with v5 asap, as it will be much more light-weight after getting rid of the old stuff, but for packages still supporting older Julia, they would also keep compatibility with v4 and keep using Compat.VersionNumber, because they have to.
For those functions which required the Compat. before, I think we went with the deprecate in v5, remove in v6 scheme. But those were only few. If this now concerns every piece of Compat, the keep in v5 as no-op, deprecate in v6, remove in v7 might be in order.
As argued by @KristofferC ion #811 (comment) (and I tend to agree), Compat should not commit type piracy by adding methods to Base functions for Base types, but rather define distinct functions of the same name, so that usage needs to be explicit opt-in (by qualification or explicitly named
using
).This is different from how we used to do it, by I think it's worthwhile.
If we agree to do it this way, we should start by applying this rule to any new features. I'm not sure we should also go to the trouble of deprecating the old style in favor of the new style for existing features. Anyway, this likely warrants some discussion before setting anything in motion.
The text was updated successfully, but these errors were encountered: