at-kwdef support for parametric types and subtypes

[simonbyrne]

Fixes #29307.

[simonbyrne]

I have no idea what is happening, but I get this locally:

Generating precompile statements...┌ Error: Failed to precompile precompile(Tuple{typeof(Base.show), Base.IOContext{Base.TTY}, Type{Vararg{Any, N} where N}})
└ @ Main.anonymous /Users/simon/src/julia/contrib/generate_precompile.jl:169
ERROR: LoadError: LoadError: TypeError: in Type, in parameter, expected Type, got Type{Vararg{Any,N} where N}

any ideas?

[KristofferC]

Seems like another manifestation of #28808.

There is already one workaround at

julia/contrib/generate_precompile.jl

Line 165 in 2fd386c

occursin("\"YYYY-mm-dd\\THH:MM:SS\"", statement) && continue

, perhaps just add this one as well?

[mauro3]

Adding this makes it compile:
statement == "precompile(Tuple{typeof(Base.show), Base.IOContext{Base.TTY}, Type{Vararg{Any, N} where N}})" && continue

I was not aware that @kwdef strives for "feature completeness". But this PR nearly puts it there, so whilst you're at it, maybe also add:

# allow inner constructors
# (assume one will be the full positional one)
Base.@kwdef struct A
    a = 1
    A(a) = (@assert a>1; new(a))
end
# -> ERROR: syntax: "A(a)" is not a valid function argument name

# Closures
const b = 7
Base.@kwdef struct B
    a::Int=b
end
B() # ERROR: UndefVarError: b not defined

Also, here some tests, adapted from Parameters.jl, which might be good to add: https://gist.github.com/mauro3/6a700f5b6fe09b4d0c130c354a8178ac. (although, I did not check which ones are redundant with the already existing ones).

[simonbyrne]

Thanks for the fix and the examples. I'm not sure what you mean by "feature completeness", but if it exists, it might as well be correct.

[mauro3]

Sorry, with "feature complete" I meant what the equivalent macro @with_kw in Parameters.jl supports. Looks like I can drop that part of Parameters.jl, thanks!

How about adding to the docs something like: "If inner constructors are defined, then @kwdef assumes that one is the positional constructor of all fields."

[simonbyrne]

Makes sense: what else is missing compared with @with_kw?

How about:

Inner constructors can still be defined, but should accept arguments in the same form as the default inner constructor (i.e. one positional argument per field) in order to function correctly with the keyword outer constructor.

[mauro3]

Four bits which are "missing" are:

• allow @asserts in the type body which then get included in the positional inner constructor.
• different show method.
• type-specific unpack macros
• automatic documentation of the type-fields with their defaults

I don't think the first three are suitable for Base. The last would be nice though, but maybe for another PR.

Inner constructors can still be defined, but one needs accept arguments in the same form as the default inner constructor (i.e. one positional argument per field) in order to function correctly with the keyword outer constructor.

[mauro3]

Wait, there is another useful one:

i1 =  SomeType(a=77, b=0,...)
i2 = SomeType(i1, b=9) # takes all of i1's values except the ones defined with the kw

x-ref: #5333

[simonbyrne]

I can see that last one would be useful, but there is the question of what to do if the struct takes a single field. e.g.

struct SomeType
   a
end

then what should

SomeType(SomeType(a=1))

give?

[mauro3]

Just SomeType(1), no?

[simonbyrne]

How would you construct the nested type?

[simonbyrne]

It's a pity we can't overload splatting, then we could use the syntax

SomeType(SomeType(a=1)...; a=2)

At the moment that would require writing an iterator over the object.

[mauro3]

How would you construct the nested type?

I see the problem. But you already figured out the solution:

It's a pity we can't overload splatting

but you should probably implement that in a separate PR. ;-)

No, more seriously, probably leave that feature for now. Alternatively, just forget about the nested type in the one-field case.

[simonbyrne]

Okay, I think this is ready to merge.

[mauro3]

LGTM except the doc-string update:

Inner constructors can still be defined, but one needs to accept arguments in the same form as the default inner constructor (i.e. one positional argument per field) in order to function correctly with the keyword outer constructor.

[simonbyrne]

Done.

[mauro3]

So this will be in 1.1, right?

[simonbyrne]

Yes, though it shouldn't be breaking, so we could backport if you wanted it?

[StefanKarpinski]

Features don't go in point releases.

[simonbyrne]

I would argue this is a bugfix rather than a feature. (from https://discourse.julialang.org/t/kwdef-not-working-for-parametric-struct/25286/4)

[fredrikekre]

It's not even exported.