Turn unspecified defaults in at-kwdef into required kwargs

[ararslan]

The existence of @kwdef predates the existence of required keyword arguments; before that, all keyword arguments needed a default value. So currently when no value is specified for a field in the type definition given to @kwdef, it's assigned a default value based on the field's type.

Now, with this change, any field not explicitly given a default becomes a required keyword argument in the resulting type constructor when using @kwdef. In doing this, we're also able to drop the requirement that the type's fields be typed, and that the type has fields at all. That is, we can now allow

@kwdef struct A
    a = 1
end

as well as

@kwdef struct A end

(though of course the latter case isn't particularly useful).

Lastly, this adds type assertions to the keyword arguments in the resulting constructor. That piece has been removed.

Fixes #27970.

[simonbyrne]

Seems like a good idea.

[JeffBezanson]

this adds type assertions to the keyword arguments in the resulting constructor

I'm all in favor of the rest of the change, but I'm not sure about this one. Usually we generate constructors that accept any arguments and convert to the field types.

[ararslan]

Okay I've removed that change.

[stevengj]

This should work if you just do = 0, right?

[ararslan]

It didn't until I removed the assertion that Jeff mentioned, so it does work now. I'd rather not go back through and change all of these to be less explicit though.

[simonbyrne]

Maybe add an explicit test for the auto-conversion? e.g.

@test Test27970Typed(a=0x03) == Test27970Typed(3)

[ararslan]

Suggested test has been added.

[ararslan]

Anyone want to take another look?

[marius311]

What do you guys think about, if the type is a mutable struct, then fields without default values which are not specified via keyword arguments remain undefined and can be set later?

[ararslan]

IMO that seems a little finnicky and easy to forget that the behavior differs based on whether the type is mutable.

[simonbyrne]

Also, "undefined" is a bit of weird edge case that we don't really want to encourage, or at the very least, we want to be explicit (hence the undef argument for array creation).

[marius311]

easy to forget that the behavior differs based on whether the type is mutable.

Yea, that's true. What about an option, say,

julia> @kwdef allow_undef=true mutable struct Foo
   x=2
   y
end

julia> Foo()
Foo(2, #undef)

This could work for both mutable/immutable (although in the latter case is likely less useful). Granted this probably significantly increases the complexity of writing the macro.

or at the very least, we want to be explicit (hence the undef argument for array creation)

That's fair, although in this case AFAIK I can't explicitly leave a field undefined using any outer constructor, right? I suppose another solution for me would be to allow "setting" something as #undef from an outer constructor (which could potentially make writing the allow_undef=true version pretty trivial). Are there any thoughts on allowing this?