Autogenerate `(::Type{Foo})(x::T, y) where T` constructor for type Foo{T}

[jakobnissen]

Consider a definition of a parameter-less struct:

struct Bar
    x::Int
    y::Float64
end

This creates two constructors: A fully specified Bar(x::Int64, y::Float64) and a fully unspecified Bar(x, y). The latter is very convenient because you can just do Bar(1, 1) and it will automatically convert.

For a simple struct with a type param, we have something similar:

struct Baz{T}
    x::T
end

creates the specified (::Type{Baz{T}})(x) where T and the unspecified (::Type{Baz})(x::T) where T. The latter handily allows you to call Baz(1.0) and get exactly what you expect.

However, if you make:

struct Foo{T}
    x::T
    y::Float64
end

You get (::Type{Foo{T}})(x, y) where T and (::Type{Foo})(x::T, y::Float64) where T. But there is no equivalent convenience method (::Type{Foo})(x::T, y) where T that allows you to do Foo(1, 1) and have it work. That would be nice to have though.

This was raised by @arnavs on Slack who found it counterintuitive.

[KlausC]

This was again blamed in https://julialang.slack.com/archives/C6A044SQH/p1587849615486300

[jbaron]

Would be indeed great if the generated constructors behave the same for structs with and without parameters. Bitten me now a few times during the refactoring of some code and I see no upside of having this different behavior in place.

[AzamatB]

Bump. I was bitten by this.

[cstjean]

Related: #17186

[nandoconde]

(Bump again, as raised in issue #41241)

I have a question: is there a difference between the constructors you propose
(::Type{Foo})(x::T, y) where T
and those proposed in the closed issue,
Foo(x::T, y) where {T} = Foo{T}(x, y)
?

[albheim]

Also bitten by this.

And @nandoconde it seems like they might be slightly different, but I don't fully understand exactly what the difference here is. Or maybe it becomes the same if you go even lower.

julia> struct A{T}
       b::T
       end

julia> Meta.@lower A(x::T) where T = A{T}(x)
:($(Expr(:thunk, CodeInfo(
    @ none within `top-level scope`
1 ─      $(Expr(:thunk, CodeInfo(
    @ none within `top-level scope`
1 ─     return $(Expr(:method, :A))
)))
│        $(Expr(:method, :A))
│   %3 = Core.TypeVar(:T)
│   %4 = Core.Typeof(A)
│   %5 = Core.svec(%4, %3)
│   %6 = Core.svec(%3)
│   %7 = Core.svec(%5, %6, $(QuoteNode(:(#= REPL[4]:1 =#))))
│        $(Expr(:method, :A, :(%7), CodeInfo(
    @ REPL[4]:1 within `none`
1 ─ %1 = Core.apply_type(A, $(Expr(:static_parameter, 1)))
│   %2 = (%1)(x)
└──      return %2
)))
└──      return A
))))

julia> Meta.@lower (::Type{A})(x::T) where T = A{T}(x)
:($(Expr(:thunk, CodeInfo(
    @ none within `top-level scope`
1 ─ %1 = Core.TypeVar(:T)
│   %2 = Core.apply_type(Type, A)
│   %3 = Core.svec(%2, %1)
│   %4 = Core.svec(%1)
│   %5 = Core.svec(%3, %4, $(QuoteNode(:(#= REPL[5]:1 =#))))
│        $(Expr(:method, nothing, :(%5), CodeInfo(
    @ REPL[5]:1 within `none`
1 ─ %1 = Core.apply_type(A, $(Expr(:static_parameter, 1)))
│   %2 = (%1)(x)
└──      return %2
)))
└──      return nothing
))))

[nsajko]

This seems like it could cause ambiguities in existing code.

[alecloudenback]

some other discussion here: #17186

I also was confused by the different behavior between parametric and non-parametric structs in this regard

[cstjean]

This seems like it could cause ambiguities in existing code.

julia> struct Foo
       x::Int
       end

julia> methods(Foo)
# 2 methods for type constructor:
 [1] Foo(x::Int64)
     @ REPL[1]:2
 [2] Foo(x)
     @ REPL[1]:2

julia> struct Bar{T}
       x::Int
       y::T
       end

julia> methods(Bar)
# 1 method for type constructor:
 [1] Bar(x::Int64, y::T) where T
     @ REPL[3]:2

If Bar also defined a Bar(x, y) = ... method, then it wouldn't cause ambiguities, but it might cause "method overwritten during precompilation" warnings/errors.