Using `@traitfn` on functions in Base?

[MilesCranmer]

First: awesome package! I really really hope Julia incorporates traits natively some day.

I was wondering what the best way is to use @traitfn on functions in Base?

For example, in DynamicQuantities.jl, I am trying to define a IsQuantity{X} trait rather than having to use <: AbstractQuantity: SymbolicML/DynamicQuantities.jl#24. This is so that I can have types be subtyped on AbstractArray, while still working with the functions in my library if they are quantity-like.

However, I quickly realized that using @traitfn on Base can invalidate methods. For example:

julia> using SimpleTraits

julia> struct MyFloat
           x::Float64
       end

julia> @traitdef IsMyFloat{X}

julia> @traitimpl IsMyFloat{MyFloat}

julia> @traitfn Base.:+(l::T, r::T) where {T; IsMyFloat{T}} = T(l.x + r.x)

julia> MyFloat(0.1) + MyFloat(0.2)
MyFloat(0.30000000000000004)

This works, but invalidates any generic methods in Base for + because it expands to:

Base.:+(l::T, r::T) where {T}

I'm assuming not, but I just wanted to hear if you know any way around this? Maybe the short answer is to avoid using @traitfn on functions in Base...

Cheers,
Miles

[mauro3]

I think in principle it should work but it is probably not a good idea as it potentially invalidates many methods and thus impacts compile time. It is also type piracy but that aspect should be ok, as long as you also define the not-method:

julia> @traitfn Base.:+(l::T, r::T) where {T; Not{IsMyFloat{T}}} = l.x + r.x

Of course, if you than add a Base-type to the IsMyFloat trait, then you have proper type piracy.

But it could well be that I didn't think this through properly. If you find a reason why it doesn't work, then please post it here.

[mauro3]

I'll close this as there is nothing actionable, but feel free to continue the discussion here.

[MilesCranmer]

Thanks. I haven't seen any problems in using it; the only issue is the invalidations. I'm not sure if there's any way around that though.

I was exploring this as an alternative to defining an abstract type that users can interface with. If there was a way around the invalidations I think it would be pretty useful:

---

Normal interface:

abstract type AbstractMyFloat end

struct MyFloat <: AbstractMyFloat
    x::Float64
end

Base.:+(x::T, y::T) where {T<:AbstractMyFloat} = T(x.x + y.x)

then the user tries extends their own type with

struct MyFloat2 <: AbstractMyFloat2,AbstractMyFloat
    x::Float64
end

But they quickly find out Julia lacks multiple inheritance so this does not work, and the user is forced to choose an abstract type. (And maybe build a wrapper type to get both)

---

Trait-based interface:

@traitdef IsMyFloat{X}
@traitimpl IsMyFloat{MyFloat}

@traitfn Base.:+(x::T, y::T) where {T; IsMyFloat{T}} = T(x.x + y.x)

then the user can freely extend their own type with

struct MyFloat2 <: AbstractMyFloat2
    x::Float64
end
@traitimpl IsMyFloat{MyFloat2}

which actually works, and they get both the functions of ::::IsMyFloat as well as ::AbstractMyFloat2. The only issue is the invalidations. Maybe it's just not possible...