Area
- Incan Language (syntax/semantics)
- Tooling (CLI/formatter/test runner)
- Runtime / Core crates (stdlib/core/derive)
- Documentation
Summary
Propose an RFC for explicit representation, layout, alignment, and calling convention controls in Incan. The RFC should define how source-visible types and exported functions opt into ABI-visible representation decisions without making backend implementation details the default language contract.
This is intended as a 0.8 freestanding-foundations RFC proposal only. The actual RFC draft can be written later when the ABI and backend replacement direction have more implementation evidence.
Motivation
Freestanding targets, Rust-facing ABI, C/extern boundaries, memory-mapped hardware structures, boot protocols, and package compatibility all need clearer representation rules than ordinary hosted application code. Today, many Incan types can remain abstract or backend-owned, but low-level and ABI-facing code needs a way to say which representation choices are intentional and stable enough for a boundary.
Without an RFC, layout concerns can leak through generated Rust behavior, accidental compiler choices, or ad hoc runtime structs. That would undercut the larger goal: Incan owns its semantic types and ABI metadata instead of treating emitted backend spelling as the source of truth.
Proposal sketch
The future RFC should cover:
repr-like controls for models/classes/enums/newtypes where needed;- transparent, C-compatible, packed, aligned, or target-specific representation profiles;
- field ordering and padding policy where representation is explicit;
- enum/tag representation policy at ABI boundaries;
- alignment controls and diagnostics for invalid combinations;
- calling convention declarations for exported or imported functions;
- interaction with Rust-facing ABI, C ABI, and package metadata;
- how representation decisions appear in semantic inspection and build reports;
- which ordinary Incan types deliberately remain layout-opaque.
Possible source shapes, subject to RFC design:
@repr("c")
pub model BootInfo:
memory_map_addr: u64
memory_map_len: u64
@extern(callconv="C")
pub def kernel_main(info: Ptr[BootInfo]) -> Never:
...
The exact spelling should be decided by the RFC. The important distinction is that layout stability must be explicit and inspectable, not inferred from backend output.
Alternatives considered
- Leave all layout to the backend. Rejected because ABI-facing and freestanding code needs intentional representation contracts.
- Make every Incan model layout-stable by default. Rejected because it would freeze too much too early and constrain normal high-level application types.
- Use Rust
repr(...) directly as Incan syntax. Rejected as the final answer because Incan should own the language contract, even if Rust-compatible lowering is one backend target.
- Use only C ABI as the universal boundary. Rejected because Rust-facing, Incan-facing, metadata, and freestanding boundaries may need different stability and representation levels.
Impact / compatibility
This should be additive before 1.0. Ordinary Incan types should remain representation-opaque unless they opt into an ABI/layout profile. Once a type or function opts into a stable representation, changing that representation becomes a compatibility concern for packages and generated artifacts.
The RFC should avoid freezing a stable public ABI too early. It should define pre-1.0 controls and metadata hooks while preserving room to revise syntax and stability tiers before 1.0.
Implementation notes (optional)
Likely future implementation areas:
- parser/metadata support for representation and calling-convention declarations;
- typechecker validation for allowed representation profiles;
- ABI metadata emission for layout and call boundary facts;
- Body IR preservation of ABI-visible type and function properties;
- backend lowering to target-specific representations;
- package compatibility checks for representation changes;
- docs and inspection output explaining which facts are stable, unstable, or target-specific.
This RFC should coordinate with the freestanding target/runtime RFC and unsafe RFC, but remain separate so 0.8 does not collapse all low-level concerns into one oversized document.
Checklist
Area
Summary
Propose an RFC for explicit representation, layout, alignment, and calling convention controls in Incan. The RFC should define how source-visible types and exported functions opt into ABI-visible representation decisions without making backend implementation details the default language contract.
This is intended as a 0.8 freestanding-foundations RFC proposal only. The actual RFC draft can be written later when the ABI and backend replacement direction have more implementation evidence.
Motivation
Freestanding targets, Rust-facing ABI, C/extern boundaries, memory-mapped hardware structures, boot protocols, and package compatibility all need clearer representation rules than ordinary hosted application code. Today, many Incan types can remain abstract or backend-owned, but low-level and ABI-facing code needs a way to say which representation choices are intentional and stable enough for a boundary.
Without an RFC, layout concerns can leak through generated Rust behavior, accidental compiler choices, or ad hoc runtime structs. That would undercut the larger goal: Incan owns its semantic types and ABI metadata instead of treating emitted backend spelling as the source of truth.
Proposal sketch
The future RFC should cover:
repr-like controls for models/classes/enums/newtypes where needed;Possible source shapes, subject to RFC design:
The exact spelling should be decided by the RFC. The important distinction is that layout stability must be explicit and inspectable, not inferred from backend output.
Alternatives considered
repr(...)directly as Incan syntax. Rejected as the final answer because Incan should own the language contract, even if Rust-compatible lowering is one backend target.Impact / compatibility
This should be additive before 1.0. Ordinary Incan types should remain representation-opaque unless they opt into an ABI/layout profile. Once a type or function opts into a stable representation, changing that representation becomes a compatibility concern for packages and generated artifacts.
The RFC should avoid freezing a stable public ABI too early. It should define pre-1.0 controls and metadata hooks while preserving room to revise syntax and stability tiers before 1.0.
Implementation notes (optional)
Likely future implementation areas:
This RFC should coordinate with the freestanding target/runtime RFC and unsafe RFC, but remain separate so 0.8 does not collapse all low-level concerns into one oversized document.
Checklist