# RFC: Language Support for Traits — Yay or Nay?

**URL:** <https://discourse.julialang.org/t/rfc-language-support-for-traits-yay-or-nay/93914>\
**Category:** Internals & Design\
**Tags:** question, proposal, inheritance, traits, interface\
**Created:** [February 2, 2023, 11:10am UTC](https://discourse.julialang.org/t/rfc-language-support-for-traits-yay-or-nay/93914 "2023-02-02T11:10:06Z")\
**Posts on this page:** 1\
**Showing post:** 26

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [February 4, 2023, 6:43am UTC](https://discourse.julialang.org/t/rfc-language-support-for-traits-yay-or-nay/93914/26 "2023-02-04T06:43:14Z")

</div>

> [@uniment](#):
>
> Naturally we would wish to extend this idea, to be able to dispatch on the _traits_ of the element type. But this proposal offers no such mechanism. ☹

What I think you’re looking for is the sort-of dual to `Union` - instead of being a subtype of one of its parameters, you’d want to require `T` to be a subtype of ALL of its parameters (I don’t recall the proper type theoretic name, so I’ll just call this `Join` for now - think of it as a non-eager `typejoin`, just aggregating types without collapsing to `Any` or some `Union`). That is, in your `Platypus` example you’d write it like

```julia
abstract type HasDuckBill end
abstract type LaysEggs end

abstract type Mammal end

struct Platypus <: Join{HasDuckBill, LaysEggs, Mammal} end
struct CanadianGoose <: Join{HasDuckBill, LaysEggs, Bird} end

foo(arr::AbstractArray{T}) where {T <: Join{HasDuckBill, LaysEggs}} = "Platypus or Goose"

```

This can of course lead to lots of ambiguity errors, e.g. if we just add the innocent looking

```julia
foo(arr::AbstractArray{T}) where {T <: Mammal} = "Not a bird!"

```

then

```julia
foo(Platypus[])

```

is ambiguous. This particular approach still has the disadvantage of not being able to easily add new traits to existing objects, since it keeps the type system of julia nominal (see [the docs](https://docs.julialang.org/en/v1/manual/types/) and [wikipedia](https://en.wikipedia.org/wiki/Nominal_type_system)). This is in principle fixable - just don’t require `Join` to be declared a supertype, i.e. don’t make it a nominal part of the type system - but I haven’t thought about the consequences of that too deeply. It’s so far the best I’ve come up with to introduce traits & multiple abstract subtyping to julia though 🤷 I quite like it, but solving the issues with it I haven’t found yet and actually implementing that is probably worth a master level thesis (who knows, maybe I’ll come back to this approach when I go for a masters…)

---

_[View the full topic](https://discourse.julialang.org/t/rfc-language-support-for-traits-yay-or-nay/93914)._