As I mentioned in the opening line, this Pre-Pitch is motivated by that discussion. However, I opted to break this out into its own thread as that one is already quite long (>130 posts) and has been dormant for several weeks now.
Additionally, the syntactical approach and capabilities between the pitches are quite different, with this as struct approach purposely targeting more minimal additions that compose well with current syntax. The approach proposed in Anonymous Structs requires the following grammar changes:
type-closure-expression → { type-capture-list }
type-closure-expression → { statements? }
type-closure-expression → { type-closure-signature in statements? }
type-closure-expression → { type-closure-signature in getter-setter-block }
type-closure-expression → { type-closure-signature in struct declarations? }
type-closure-signature → type-capture-list? closure-parameter-clause throws? function-result?
type-closure-signature → type-capture-list
closure-parameter-clause → ( ) | ( closure-parameter-list ) | identifier-list
closure-parameter-list → closure-parameter | closure-parameter , closure-parameter-list
closure-parameter → closure-parameter-name type-annotation
closure-parameter-name → identifier
type-capture-list → [ type-capture-list-items ]
type-capture-list-items → type-capture-list-item | type-capture-list-item , type-capture-list-items
type-capture-list-item → attributes? type-capture-specifier? expression
type-capture-specifier → var | weak var? | unowned var? | unowned(safe) var? | unowned(unsafe) var?
by contrast, the pitch here only requires the following:
primary-expression → tuple-as-struct-expression
tuple-as-struct-expression → tuple-expression as type? struct
where type? in tuple-as-struct-expression is constrained to a protocol or protocol composition type.
Other differences include:
- Direct member access support without explicit protocol conformance
- No support for property wrapper syntax
- All synthesized properties are var by default