Julia: Printing of the `typ` field in `Expr` objects

[dalum]

Should the typ field in Expr objects be printed differently? I'm not sure how, but this seems wrong:

julia> e = Expr(:call, :+, :a, :b)
julia> e.typ = Float64
julia> e
:((a + b)::Float64)

julia> a = 4; b= 6
julia> eval(e)
10

julia> eval(:((a + b)::Float64))
ERROR: TypeError: typeassert: expected Float64, got Int64

Tangentially related (perhaps this should be in another issue), it would be nice if the typ field could be specified as a keyword argument of the constructor. I tried to fiddle with it in base/boot.jl, but couldn't even get it to compile.

[yuyichao]

What's wrong about it?

[vtjnash]

This field is going away soon.

[dalum]

Oh, sorry, the thing that is wrong is that the expression with the typ field set is not actually equal to the expression (a + b)::Float64.

I wanted to use the typ field to store the expected return type, but if it is being deprecated, then I will find another way to do it.

[yuyichao]

The .typ field has always been an internal field that will not be generated by the frontend (parser) and will not roundtrip through it (lowering) either. It is only used as a way to store inference result and is printed as valid julia syntax. Since no expression parses to it we will never print it as a expression that parses back to the typed expression, whether we'll remove it or not. Also since it's an internal field, removing it will not be considered a breaking change.

[dalum]

Oh, then I think the chapter dealing with metaprogramming in the docs needs to be updated, because it explicitly says about the typ field that "[it is] the expression result type, which may be annotated by the user or inferred by the compiler (and may be ignored completely for the purposes of this chapter)".

[StefanKarpinski]

In general, the .typ field should be considered private. The statement in the docs that the user can set it is not really accurate and should be removed. Of course, since the field is going away entirely soon, that will also address the issue.

[tkelman]

Unless whoever changes the functionality forgets to update the docs

[fredrikekre]

reopening as a doc issue then, see #23082