VX
Vexel Anti-goals Doctrine by refusal

Role: Anti-goals

Vexel refuses features that erase compiler certainty.

This page is a filter. If these refusals conflict with your priorities, Vexel is likely not the right fit.

Refusal is a design tool: fewer escape hatches, stronger global proof.
Opening refusal: Vexel does not optimize for unrestricted local freedom; it optimizes for provable global behavior.

Rejected Assumptions

"Pointer freedom is mandatory"

Rejected. Raw pointer arithmetic destroys whole-program reasoning and makes CTE/DCE less trustworthy.

"Generators should own compile-time logic"

Rejected. Tool-splitting fragments semantics across layers and weakens compiler visibility.

"Implicit runtime behavior is acceptable"

Rejected. Hidden behavior cannot be validated by frontend analysis and contracts.

"Ergonomic defaults outrank explicit tradeoffs"

Rejected. Vexel keeps tradeoffs visible: fewer escape hatches in exchange for stronger compiler proof.

Why Pointers Are Rejected

Vexel is built around whole-program analysis. Pointer arithmetic allows alias patterns that are difficult to prove globally. Removing that freedom enables stronger compile-time execution and dead-code elimination guarantees.

Why Tool-splitting Is Rejected

In Vexel, compile-time behavior belongs in the language/compiler pipeline, not in external code generators. This keeps ownership clear and behavior testable in one place.

What Freedom Vexel Does Not Prioritize

  • Unconstrained pointer-level mutation as a default coding model.
  • Opaque runtime side effects hidden from analysis passes.
  • Architecture drift introduced by convenience shortcuts.

Filter Line

If your primary requirement is unconstrained low-level mutation first and compiler reasoning second, Vexel is intentionally not optimized for that workflow.
Read formal law Read analysis model Source markdown