Slopjective-C

Burning the slurp juice at both ends to make the future we deserve

Try not to expend any real human effort on this, instead go buy the pro subscription for the LLM of your choice and have it do that for you.

Additionally, you should consider giving me money so I can buy more slurp juice (tokens)

---

Objective‑C 3.0 Draft Specification (Working Draft)

Working draft: v0.10
Last generated: 2025-12-28

This repository contains a working draft specification for Objective‑C 3.0. The draft is organized into small, implementable parts, with explicit contracts for separate compilation, module metadata, and (where needed) ABI/runtime hooks.

Published draft

The stitched draft is published on GitHub Pages: https://doublemover.github.io/Slopjective-C/ The build uses the Table of Contents ordering and excludes this README. Source markdown lives in spec/ for local edits.

What this spec is

• A language-mode specification (“ObjC 3.0 mode”) layered on top of today’s de‑facto Objective‑C (Clang/LLVM + modern runtime behavior).
• A set of normative requirements (RFC-style “shall/must”) intended to be testable by compilers/toolchains.
• A design that prioritizes incremental adoption: new defaults and stricter rules are opt‑in via mode + strictness levels.

What this spec is not

• Not a rewrite of baseline Objective‑C, ARC, or Blocks. Where those are relied upon, this draft references them as baseline behavior and specifies only the extensions/constraints needed for ObjC 3.0.
• Not a full “standard library spec” for every API. Where features are library-defined (e.g., task spawning), this draft specifies the minimum required surface and the compiler hooks needed for diagnostics.

How the documents are organized

Start here:

• Table of Contents — Index of all parts.
• Introduction — Goals, non‑goals, and cross‑cutting principles.

Front matter (implementation-facing):

• Decisions Log — Explicit ship/no‑ship decisions to keep v1 implementable.
• Attribute and Syntax Catalog — Canonical spellings for attributes/pragmas that must survive interface emission.
• Lowering and Runtime Contracts — ABI/lowering/runtime obligations (separate compilation contract).
• Module Metadata and ABI Tables — Normative tables for required module metadata and ABI boundaries.
• Conformance Profile Checklist — Checklists for conformance claims (Core/Strict/Strict Concurrency/Strict System + optional feature sets).

Language parts:

• Part 0 — Baseline and Normative References — Baseline definitions and normative terminology.
• Part 1 — Versioning, Compatibility, and Conformance — Mode selection, feature tests, strictness levels, and migration requirements.
• Part 2 — Modules, Namespacing, and API Surfaces — Modules, module-qualified names, API surface contracts, interface emission.
• Part 3 — Types: Nullability, Optionals, Pragmatic Generics, and Typed Key Paths — Nullability defaults, optionals, pragmatic generics, typed key paths.
• Part 4 — Memory Management and Ownership — ARC baseline + ownership/transfer/lifetime rules used by other features.
• Part 5 — Control Flow and Safety Constructs — defer, guard, match, patterns.
• Part 6 — Errors: Result, throws, try, and Propagation — throws/try/do-catch, Result, propagation operator ?, NSError/return-code bridging.
• Part 7 — Concurrency: async/await, Executors, Cancellation, and Actors — async/await, executors, tasks, cancellation, actors, Sendable-like checking.
• Part 8 — System Programming Extensions — Resource cleanup, retainable C families, borrowed pointers, capture lists.
• Part 9 — Performance and Dynamism Controls — direct/final/sealed intent and dynamism boundaries.
• Part 10 — Metaprogramming, Derives, Macros, and Property Behaviors — derives, AST macros, property behaviors.
• Part 11 — Interoperability: C, C++, and Swift — C/C++/Swift interop expectations.
• Part 12 — Diagnostics, Tooling, and Test Suites — Required diagnostics, migrators, and conformance test suite expectations.

Suggested reading order

1. Introduction (what the project is trying to accomplish)
2. Part 1 — Versioning, Compatibility, and Conformance (how mode/strictness/conformance works)
3. Attribute and Syntax Catalog / Lowering and Runtime Contracts / Module Metadata and ABI Tables (the “separate compilation contract” and canonical spellings)
4. Then pick a feature slice:
   • Types/Optionals: Part 3
   • Errors: Part 6
   • Concurrency: Part 7
   • System programming: Part 8

Conformance model (quick summary)

A toolchain makes a conformance claim against named profiles:

• Core: language mode + modules/metadata + types/errors/concurrency baseline.
• Strict: stronger diagnostics and migration support.
• Strict Concurrency: actor/executor/Sendable-like enforcement.
• Strict System: resource/borrowed-pointer/capture-list enforcement.

See the Conformance Profile Checklist for the definitive checklist.

Contributing / feedback

This is a working draft. Each part ends with an Open issues section.

A practical contribution style:

• pick one “Open issue”,
• propose a concrete rule + lowering/metadata implications,
• add (or outline) conformance tests for it.

Lint and CI requirements are documented in CONTRIBUTING.md.

License

(Not specified in this draft bundle — add a repository-level license file if you plan to publish/distribute.)