Tuple{} vs tuple() in Generated Function Vararg type

[simonster]

Consider:

julia> @generated function f(x...)
           println("x in generated function: ", x)
           :(println("typeof(x) in function that is run: ", typeof(x)))
       end;

julia> f(1, 2)
x in generated function: (Int64,Int64)
typeof(x) in function that is run: Tuple{Int64,Int64}

As you can see, x in the generated function is not actually the type of x in the method that is run. I would have expected that both would be Tuple{Int64,Int64}.

[mbauman]

See comments at #10380 (comment) and following. If we were to change this, I think we need a Tuple API first.

Edit to add: Another reason to do this is that it would be nice to use Tuple subtype relationships in some cases (like here: base/abstractarray.jl#L502 )

[JeffBezanson]

Yeah, on further reflection I think this is actually better. If tuple types are easier to access it makes even more sense.

[quinnj]

Giving a bump here as I recently ran into wanting tuple types being easier to work w/.

[JeffBezanson]

Here's one problem. Given

@generated f(x...) = # something

For the call f(Int, Int) you currently get x = (Type{Int}, Type{Int}) when the generator is called. However, at run time typeof(x) is going to be Tuple{DataType, DataType}, so binding x to that at code generation time loses information.

[StefanKarpinski]

We may want to consider generated functions to be an unstable feature even post 1.0.

[JeffBezanson]

I propose closing this.

[JeffBezanson]

Passing a tuple here doesn't bother us enough to be worth changing.