Björkus "No time_t to Die" DorkusStructural Typing in C!!! Finally done hammering on this damn thing. Fuck.
https://thephd.dev/_vendor/future_cxx/papers/C%20-%20_Record%20types.html
Fuck!!
Stephen Heumann@thephd Some thoughts from the maintainer of a small C implementation:
1. I think structural typing in C would be valuable.
@thephd 2. I'm not sure _Record is a good name for it. To me, this calls to mind records in Pascal, which are essentially its version of structures and/or unions and do not have structural compatibility rules. The term "record" is also used in several other programming languages and in databases, often not with the meaning you're giving it. A possible alternative that comes to mind is "tuple", although that corresponds most naturally to what you call _Record(types).
@thephd 3. I'm not entirely convinced that having _Record, _Record(types), and potentially _Record(other::attributes) is valuable enough to justify the complexity of it. I'd be tempted to just specify one version and leave any implementation-specific variants up to the regular attribute syntax.
@thephd 4. Please make sure the standard wording reflects what you intend with regard to the interaction between _Record and anonymous structures and unions. For example, can an anonymous structure or union in a structure type declared with _Record(types) match with a named member of another for type compatibility purposes? I'd suggest including examples of these cases. (Also, your document seems to use "anonymous structure" differently from the definition in the standard, which is confusing.)
@thephd 5. Can named and unnamed bit-fields match each other when using _Record(types)? I think the answer is yes based on the proposed wording, but this gives rise to a slightly odd situation where two compatible structure types may have different numbers of initializable members. Whatever the answer winds up being, I'd suggest including an example.
@thephd 6. It would be nice to have better handling in the standard for situations where one structure type is an "extended" version of another, with extra members added. Maybe out of scope for this proposal, but it seems potentially related.
@sheumann I don't really have any connotation for "extending a base type with more members" because that's just inheritance to my brain. You could make a version of composition where you can add a member to a structure and then give it a way to say "actually, all of my members are part of the thing you put me inside". That might give you the layout of composition but the "feel" of extension/inheritance that you're looking for.
When I write "anonymous" in my prose, I'm just referring to structures and unions without tags. The official standardese is very clear that we are not modifying the base algorithm: however you were comparing bitfields before, and however you were comparing anonymous unions/structures before, you keep doing that just with the strcmp for the names removed for _Record(types). For just _Record, the tag name at the top level is ignored, but everything else proceeds as normal.
I don't think I want regular attribute syntax, due to attributes being ignorable. This cannot be ignorable: it changes the way code is written, and changes a fundamental property (compatibility rules). I wouldn't mind discarding _Record(types) and _Record(vendor::stuff) to just keep the base one, though it should be known that doing so will cook usecases.
I'm glad you think structural typing is valuable! Hopefully we can make progress with something along the lines of _Record.