TL;DR: What: A new Base module called Structs providing convenience constructor macros, standardized field defaults and tags, and utilities for programmatically constructing and accessing objects; this will dramatically simplify various serialization/deserialization efforts across the ecosystem Why in Base: Consolidation/standardization of a few ecosystem efforts, parity with other comparable language offerings, functionality that is "close" to structs/struct definitions Current Code: The current Structs code exists in an unregistered repo Problems and Proposals Constructor reflection: Default constructors require all fields to be passed in definition order. The presence of inner or outer constructors can change that, with no simple way to know the default constructor isn't available. The @kwdef macro provides a standardized way for construction via fields passed as keyword arguments to the constructor, but without a simple programmatic way to know @kwdef is supported. Another pattern, more common in other languages like Java, is defining a "no-arg" or empty constructor for a mutable struct and then setting fields separately. This can easily be achieved in Julia by defining an empty construtor on a mutable struct, but again, there's no signal that the struct supports this "no-arg" construction.Proposal: Structs becomes the "home" for the @kwdef macro, and an additional @noarg macro, which would generate an empty inner constructor, allow field defaults (like @kwdef), and set default fields appropriately in the empty constructor. In addition to these macros, Structs.kwdef(::Type{<:T}) = true or Structs.noarg(::Type{<:T}) = true would also be defined when the macros are used, thus providing a programmatic inspection that a certain kind of construction method is supported. For the non-empty-non-kwdef immutable struct, it can then be assumed that the default fallback construction method is supported. Programmatic construction: With standard and kwdef/noarg construction types, we can then provide a way to programmatically construct types, which currently doesn't exist in Julia, except attempting a naive T(fields...), which can quickly run into a number of issues, like not accounting for field default values, non-default constructor thwarting, or awkwardness where not all fields can be provided.