compiler: remove anonymous struct types, unify all tuples #21817
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mlugg
added
breaking
mlugg
force-pushed
the
no-anon-structs
branch
8 times, most recently
from
8db94ce to
5da3d6c
Compare
This commit reworks how anonymous struct literals and tuples work.
Previously, an untyped anonymous struct literal
(e.g. `const x = .{ .a = 123 }`) was given an "anonymous struct type",
which is a special kind of struct which coerces using structural
equivalence. This mechanism was a holdover from before we used
RLS / result types as the primary mechanism of type inference. This
commit changes the language so that the type assigned here is a "normal"
struct type. It uses a form of equivalence based on the AST node and the
type's structure, much like a reified (`@Type`) type.
Additionally, tuples have been simplified. The distinction between
"simple" and "complex" tuple types is eliminated. All tuples, even those
explicitly declared using `struct { ... }` syntax, use structural
equivalence, and do not undergo staged type resolution. Tuples are very
restricted: they cannot have non-`auto` layouts, cannot have aligned
fields, and cannot have default values with the exception of `comptime`
fields. Tuples currently do not have optimized layout, but this can be
changed in the future.
This change simplifies the language, and fixes some problematic
coercions through pointers which led to unintuitive behavior.
Resolves: ziglang#16865
I was just bitten by this footgun, where I actually wanted `sliceAsBytes` but unintentionally used `asBytes`, which in practice ignored all but the first element. Just add a comptime assertion to trigger a compile error in this case.
mlugg
force-pushed
the
no-anon-structs
branch
from
5da3d6c to
24babde
Compare
scheibo
added a commit
to scheibo/zigpkg
that referenced
this pull request
Nov 4, 2024
scheibo
added a commit
to pkmn/engine
that referenced
this pull request
Nov 4, 2024
bobf
added a commit
to jetzig-framework/zmd
that referenced
this pull request
Nov 5, 2024
bobf
added a commit
to jetzig-framework/jetzig
that referenced
this pull request
Nov 6, 2024
jiacai2050
added a commit
to jiacai2050/zigcli
that referenced
this pull request
Nov 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit reworks how anonymous struct literals and tuples work.
Previously, an untyped anonymous struct literal (e.g.
const x = .{ .a = 123 }) was given an "anonymous struct type", which is a special kind of struct which coerces using structural equivalence. This mechanism was a holdover from before we used RLS / result types as the primary mechanism of type inference. This commit changes the language so that the type assigned here is a "normal" struct type. It uses a form of equivalence based on the AST node and the type's structure, much like a reified (@Type) type.Additionally, tuples have been simplified. The distinction between "simple" and "complex" tuple types is eliminated. All tuples, even those explicitly declared using
struct { ... }syntax, use structural equivalence, and do not undergo staged type resolution. Tuples are very restricted: they cannot have non-autolayouts, cannot have aligned fields, and cannot have default values with the exception ofcomptimefields. Tuples currently do not have optimized layout, but this can be changed in the future.This change simplifies the language, and fixes some problematic coercions through pointers which led to unintuitive behavior.
Resolves: #16865