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
Base.@irrational creates types of Irrational{:sym}. This means that there is no way to namespace new irrational values, they all share the same symbol slot in the Irrational type parameter.
This is a problem for packages that try to define new irrational numbers. If two packages define numbers with the same name but different values, it is undefined what value will actually be used which can be a quite severe bug.
I think we should state in the docstring that packages should not use this macro since it is currently so brittle.
It is also probably a good idea to think about a design that does not have this issue. Something with an abstract super type AbstractIrrational and having the macro create a new type that is a subtype of that seems like it should be workable:
abstract type AbstractIrrational end
struct Euler <: AbstractIrrational end
const euler = Euler()
@eval BigFloat(::Euler) = $(exp(big(1)))
Float64(::Euler) = 2.71828182845904523536
and then have methods defined on AbstractIrrational.
The text was updated successfully, but these errors were encountered:
I tried to implement such a macro that creates subtypes of AbstractIrrational: JuliaMath/IrrationalConstants.jl#19 It's heavily based on the implementation of Base.@irrational and still needs more tests but at least simple tests already pass.
Base.@irrational
creates types ofIrrational{:sym}
. This means that there is no way to namespace new irrational values, they all share the same symbol slot in theIrrational
type parameter.This is a problem for packages that try to define new irrational numbers. If two packages define numbers with the same name but different values, it is undefined what value will actually be used which can be a quite severe bug.
I think we should state in the docstring that packages should not use this macro since it is currently so brittle.
It is also probably a good idea to think about a design that does not have this issue. Something with an abstract super type
AbstractIrrational
and having the macro create a new type that is a subtype of that seems like it should be workable:and then have methods defined on
AbstractIrrational
.The text was updated successfully, but these errors were encountered: