# Can \`where\` constrain type parameters that are instances, like \`where {T isa Symbol}\`

**URL:** <https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443>\
**Category:** General Usage\
**Tags:** parametric-types, parametric-methods\
**Created:** [May 22, 2022, 12:31am UTC](https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443 "2022-05-22T00:31:22Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 22, 2022, 12:31am UTC](https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443/1 "2022-05-22T00:31:22Z")

</div>

`where` clauses can constrain type parameters that are types e.g. `where T <: Number`, but I’m interested in constraining instances e.g. `where T isa Symbol` vs. `where T isa Integer`, which is not valid syntax. Is there a way to do that? I know I can work around it, but I wonder if there’s a clean way to use the typical multimethod dispatch.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [May 22, 2022, 1:15am UTC](https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443/2 "2022-05-22T01:15:04Z")

</div>

what do you want to do with this?

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 22, 2022, 2:01am UTC](https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443/3 "2022-05-22T02:01:57Z")

</div>

No use case in mind, but dispatching to different methods depending on different constraints:

```julia
f(x::Val{S}) where S isa Symbol = Symbol(S, :v2)
f(x::Val{N}) where N isa Integer = N + 1

```

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [May 22, 2022, 2:11am UTC](https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443/4 "2022-05-22T02:11:10Z")

</div>

you’re taking detours for no reason:

```julia
julia> f(x::Symbol) = Symbol(x, :v2)
f (generic function with 2 methods)

julia> f(:bb)
:bbv2

julia> f(N::Integer) = N + 1
f (generic function with 3 methods)

julia> f(2)
3

```

* * *

in general, Julia does not like dispatch-by-value, nor does it support computed types, see [GitHub - vtjnash/ComputedFieldTypes.jl: Build types in Julia where some fields have computed types](https://github.com/vtjnash/ComputedFieldTypes.jl) FYI

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 22, 2022, 3:28am UTC](https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443/5 "2022-05-22T03:28:43Z")

</div>

Well, yes, but as I said, I didn’t have a use case in mind. The right-hand expressions were unimportant, that was just a minimal example of the `where` clauses I have in mind. I also am not interested in arbitrarily computing types in annotations or `where` clauses (I think I can use methods to accomplish similar things). `isa` just seems like a natural complement to `<:` for constraining type parameters, which can be either instances or types. Without it, the workaround for that example is:

```julia
f2(x::Val{T}) where T = f(T)
f(S::Symbol) = Symbol(S, :v2)
f(N::Integer) = N + 1

```

You are right about it not being idiomatic. Besides `where`-`isa` not being supported, I cannot think of any commonly used type parameter that is implemented as an instance of \>1 type. For example, there’s no such thing as a `Array{Int, :one}`; `N isa Int`.

---

<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:** [May 22, 2022, 6:00am UTC](https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443/6 "2022-05-22T06:00:48Z")

</div>

In general, no. `where` operates not on types or values directly, but `TypeVar`s - you can think of them as a placeholder for types (and `isbits` values, but those don’t have computation defined in this context) and as a tool to communicate with the specialization mechanism of the compiler.

In type-speak, julia’s dispatch/parametrization/types generally does not have [dependent types](https://en.wikipedia.org/wiki/Dependent_type) (save for the `isbits` stuff, but as you can’t compute in `where` with those, only in the function itself, it’s not quite there for fully dependent typing).

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 22, 2022, 6:56pm UTC](https://discourse.julialang.org/t/can-where-constrain-type-parameters-that-are-instances-like-where-t-isa-symbol/81443/7 "2022-05-22T18:56:43Z")

</div>

I don’t understand the type-speak stuff, but it does make sense that `where` isn’t working on types and values directly, so something like an `isa` isn’t possible. This question popped into my head because of the last two points in [this comment](https://discourse.julialang.org/t/understand-why-type-stability-depends-on-number-of-methods/81434/3); it was possible to jerry-rig a type-stability optimization by annotating a parametric method’s return type, but it seemed more natural to attempt to constrain the parameter based on the methods the parametric method would replace.