What is the main point of "where"?

General Usage
1

What is the difference between

same_type(x::T, y::T) where {T}

and

same_type{T}(x::T, y::T)

Where would “where” be REQUIRED?

Thanks,
P

2

I believe it’s intended to create a distinction between a parametric type’s constructor:

Array{T}(x) where {T} = ...

which can be called with an explicit parameter:

x = Array{Float64}(5)

and a regular method:

f(x::T) where {T} = ...

which cannot:

x = f(1.0)

and just as a way to talk about unbound type parameters in a more concrete way. For example, on julia v0.5 we have:

julia> Vector
Array{T,1}

but on julia v0.6 we have:

julia> Vector
Array{T,1} where T

which clearly shows that the T is not yet bound to anything.

1 Like
3

None.

In general, where provides a way to bind type vars in the correct scope so that Vector{Complex{T} where T <: Integer} and Vector{Complex{T}} where T <: Integer are different types (the first one being a leaftype and the second one not).

For method definition they are currently the same. The reason that we might want to deprecate the same_type{T}(...) method definition syntax is that it conflicts with constructor definition syntax. f{T}(...) where T = ... is already valid on 0.6/0.7 to define a method for f{T} where f is something that can take type parameter. The plan is to make f{Int}(...) also valid.

4
2 Likes
5

@StefanKarpinski

Thanks for the info. Very helpful.

But, let us say I have a code running in 0.5. Version 0.6 is coming so I know I will need to update, but the question is when. Release candidate is out: would you suggest the time to switch is now? Is this behavior with “where” stable?

Thanks,

Petr

6

There are a few strategies that people have been taking:

  1. just wait to update their code until v0.6 is the release (not good, if it’s a package that other people use!)
  2. make their code work on both v0.5 and v0.6 (that’s the technique I’ve been taking)
    It’s a bit more work initially, but if you have code that is being deployed on v0.5, and you don’t want to be constantly moving fixes between branches, probably the easiest approach to take.
  3. tag their code that works on v0.5, then change it to just run on v0.6, letting the package manager sort out which tagged version is used

The syntax for v0.6 should be completely frozen, only critical bug fixes / regression fixes are supposed to be going into v0.6 at this point, AFAIK. JuliaCon 2017 is only a few weeks away, and everybody really wants to see v0.6 released by then.

7
  • The where syntax is stable. The change will only be done on the old syntax.
  • You don’t need to change anything for 0.6 since the old one will behave exactly the same.
8

Great, thanks.