What is difference between Type{T} and T

vickysharma0812 · January 6, 2019, 3:42pm

Hello everyone,
I have just started to learn about Julia(<:1.0).

Unfortunately, I am not able to understand the use/functionality of Type{T}, for example, in

convert(::Type{T}, a::T) where {T<:AbstractArray} = a

why cannot we use

convert(::T, a::T) where {T<:AbstractArray} = a

please excuse me if this question is too basic.

Tamas_Papp · January 6, 2019, 3:53pm

did you read the documentation?

https://docs.julialang.org/en/v1/manual/types/#man-singleton-types-1

also, for an example,

https://docs.julialang.org/en/v1/manual/methods/#Extracting-the-type-parameter-from-a-super-type-1

Non-Contradiction · January 6, 2019, 4:12pm

The documentation of convert is

convert(T, x)

  Convert x to a value of type T.

And an example is

julia> convert(Int, 3.0)
  3

So you can see the first argument is a Type, so its type is Type{T}, and the second argument is an object to be converted to that type.

zgornel · January 6, 2019, 4:18pm

foo(::T, a::S) where {T,S} - the first argument of foo is a (non-usable) variable of type T, the second, namely a of type S.

foo(::Type{T}, a::S)- the first argument of foo is the type T, the second is of type S.

So, the difference between ::T and ::Type{T} is that they request either a variable of type T or a variable which is the type T itself. In julia types are data as well.

Indeed, this is a very basic question that is easily addressed by reading the documentation and actually running the code in question and seeing its effects.

StefanKarpinski · January 6, 2019, 6:32pm

Please everyone, keep in mind that this question was appropriately posted in the usage / first steps category. Even if something is documented, it’s still not a problem to ask a question about it! Hopefully the answers here help clarify things for @vickysharma0812.

vickysharma0812 · January 6, 2019, 6:33pm

Thank you for reply,
I have understood the usage and importance of Type{T}.

regards
Vikas

baggepinnen · January 6, 2019, 7:45pm

Type{T} is admittedly slightly unintuitive as it provides an unexpected branch in the type tree

DataType <-------- Float64
Type{Float64} <-/

julia> typeof(Float64)
DataType

julia> Float64 isa DataType
true

julia> Float64 isa Type{Float64} # This in comibnation with the next line might be unexpected
true

julia> DataType isa Type{Float64} 
false

which the documentation hints at by calling it “special”

xiaodai · January 6, 2019, 9:05pm

Just to add on, often, when you are new to something, even if you read the documentation not everything clicks. More often than not you are unsure why some passage or sentence matters until you’ve understood the concepts. This is why it’s helpful to point to the documentation and explain briefly the concepts as well.

path-doc · March 10, 2021, 2:33pm

A quick question: is DataType the root of the “type tree”?

And one longer one: how/where is this tree defined?

Tamas_Papp · March 10, 2021, 4:12pm

Think of DataType as the representation of types. I am not sure would consider the latter a tree in any sense; perhaps clarify what you mean.

carstenbauer · March 10, 2021, 4:27pm

No, Any is the root of the type tree. Putting aside that I see DataType as kind of a “meta type”:

julia> supertype(DataType)
Type{T}

julia> supertype(Type{T} where T)
Any

julia> supertype(Any)
Any

or with a small helper function:

julia> show_supertypes(T) = print(join(supertypes(T), " <: "))
show_supertypes (generic function with 1 method)

julia> show_supertypes(DataType)
DataType <: Type{T} <: Any

On a side note, if you want to see a branch of the type tree you can do

using AbstractTrees
AbstractTrees.children(x) = subtypes(x)
print_tree(Number)

to get

julia> print_tree(Number)
Number
├─ Complex
└─ Real
   ├─ AbstractFloat
   │  ├─ BigFloat
   │  ├─ Float16
   │  ├─ Float32
   │  └─ Float64
   ├─ AbstractIrrational
   │  └─ Irrational
   ├─ Integer
   │  ├─ Bool
   │  ├─ Signed
   │  │  ├─ BigInt
   │  │  ├─ Int128
   │  │  ├─ Int16
   │  │  ├─ Int32
   │  │  ├─ Int64
   │  │  └─ Int8
   │  └─ Unsigned
   │     ├─ UInt128
   │     ├─ UInt16
   │     ├─ UInt32
   │     ├─ UInt64
   │     └─ UInt8
   └─ Rational

path-doc · March 11, 2021, 1:34am

@carstenbauer, I guess you know this, but according to print_tree, DataType is a leaf on the “tree”. (It is the unique element on the branch of subtypes.)

However, according to isa (mentioned in @baggepinnen’s post), all the following evaluate to true:

isa(Type, Any)
isa(Any, Type)
isa(DataType, Any)
isa(Any, DataType).

But DataType is not really at the top/bottom of the order because, in addition, we have

isa(Type, DataType) is false
isa(DataType, Type) is true.

But also note that this violation of transitivity (DataType <: Type ~: Any ~: DataType) implies that, once we include Singleton Types, we do not have a preorder let alone a partial order or a tree.

I might try and create a graph on the basis of isa to get a lovely diagram like yours as a way of honing my Julia skills. At the moment, I can’t see a completely obvious way on the basis of the existing functions in AbstractTrees.

PS. Just out of interest, we also have

isa(typeof(Type), DataType) is true
isa(DataType, typeof(Type)) is false
and
isa(typeof(Type{T} where T), DataType) is true
isa(DataType, typeof(Type{T} where T)) is false.

path-doc · March 11, 2021, 2:11pm

PPS. How come your types are all blue and mine are not?

carstenbauer · March 11, 2021, 2:29pm

Hm? What do you mean?

Henrique_Becker · March 11, 2021, 2:40pm

He probably wrote:

```julia
code here
```

For some minimal highlight support.

Henrique_Becker · March 11, 2021, 2:50pm

I think you are confusing things. isa shows if the type of the first argument <: the second argument. So does not make sense to me to use isa to establish any ordering/tree, you should be using <: for it.

julia> Any <: Type
false

julia> Type <: Any
true

julia> Any <: DataType
false

julia> DataType <: Any
true

You should not use isa passing a type as the first argument, because it will always be the same as DataType <: second_isa_argument because the type of any type will be DataType.

goretkin · March 11, 2021, 3:11pm

That’s not true:

julia> Int64 isa Type{Int64}
true

julia> DataType <: Type{Int64}
false

I can’t find it, but there is a recording of a talk, probably given by Jeff, that shows a 2D grid layout of values, with one dimension showing a subtyping relation and another dimension showing the typeof relation. It shows the following self-loops:

julia> typeof(DataType)
DataType

julia> supertype(Any)
Any

If someone can find that talk, I would appreciate a time-link to it and a screenshot of that slide.

path-doc · March 12, 2021, 12:08am

Let’s agree that because

julia> isa(Any, DataType)
true

and

julia> isa(Any, Any)
true

we can safely say that Any is both of type Any and of type DataType. The whole point of type hierarchies is to be able to think of “meta types” as being inside the system. Otherwise we are artificially restricting ourselves to reasoning/operating at a lower level.

Let’s also agree that isa and <: can be described as two distinct binary relations, both of which describe relationships among types. You will note that on Types · The Julia Language, there are certain more abstract types where isa is used instead of <: . I expect that <: does not account for relationships higher-up the type hierarchy.

I guess the first natural question to ask is whether <: is a partial order.

Also, although my arguments in the previous post show that isa is not a preorder. They do not exclude the possibility that <: is a subrelation of isa, where some symmetry relationships under isa are broken by <: .

Henrique_Becker · March 12, 2021, 12:45am

You are correct, I forgot this exception. However, Type{T} where {T} is kinda of a special object, it represents the singleton type for which the only instance is T (this is literally the documentation of Core.Type). I believe we cannot have typeof(Int64) as Type{Int64} because then typeof(typeof(Int64)) would be Type{Type{Int64}} and so on, instead of the cycle at DataType but I am not sure what would break by doing this.

If you tried to follow what I meant by my statement then you missed it:

julia> isa(Any, DataType)
true

julia> typeof(Any) <: DataType
true

goretkin · March 12, 2021, 1:11am

As far as I understand it, that is correct, but there’s certainly reason to doubt myself and be confused about it:

github.com/JuliaLang/julia

constructors and functions behave differently with respect to `isbitstype`, `sizeof`, etc.

opened 05:00AM - 05 Dec 20 UTC

closed 02:29PM - 05 Dec 20 UTC

goretkin

For one use case, I am thinking of `Int64` and `round` as functions: ```juli…a julia> Int64(3) 3 julia> round(3) 3 ``` and I want to represent their types respectively. Unfortunately ```julia julia> isbitstype(typeof(round)) true julia> isbitstype(Type{Int64}) false ``` And more pertinent to my problem: ```julia julia> struct Foo{T} _::T end julia> Foo(round) Foo{typeof(round)}(round) julia> sizeof(Foo(round)) 0 julia> Foo(Int64) Foo{DataType}(Int64) julia> sizeof(Foo(Int64)) 8 julia> Foo{Type{Int64}}(Int64) Foo{Type{Int64}}(Int64) julia> sizeof(Foo{Type{Int64}}(Int64)) 8 ``` If I understand correctly, if `T` in `Foo{T}` is a singleton type, that is there is only one value `x::T`, then `sizeof(Foo{T})` can in principle be `0`. There is only one `x::typeof(round)` and only one `x::Type{Int64}`. (reference: https://julialang.zulipchat.com/#narrow/stream/225542-helpdesk/topic/size.20of.20tuple.20.2F.20struct.20of.20singleton.20type)