All built-in facilities must be type safe by default. Where type safety needs to be broken, it may be facilitated through explicit unsafe features. These must be marked unsafe and enabled by import from pseudo-module @@UNSAFE@@ or optional pseudo-module @@ASSEMBLER@@. No other source of unsafe facilities shall be permitted.

All built-in facilities must be type safe by default. Where type safety needs to be broken, it may be facilitated through explicit unsafe features. These must be marked unsafe and enabled by import from pseudo-module UNSAFE or optional pseudo-module ASSEMBLER. No other source of unsafe facilities shall be permitted.

When considering the addition of a feature, we looked at in the context of the weight of the entirety of features, not in isolation. We observed an imaginary baggage allowance, whereby items had to be removed to make space for others to be added. Our aim was to avoid feature creep.

All built-in facilities must be type safe by default. Where type safety needs to be broken, it may be facilitated through explicit unsafe features. These must be marked unsafe and enabled by import from pseudo-modules UNSAFE or optional pseudo-module ASSEMBLER. No other source of unsafe facilities shall be permitted.

We followed the Einsteinian '''simplicity''' principle ''“as simple as possible, not any simpler.”'' but we did not elevate simplicity to the status of dogma. Simplicity is a means to an end, not an end of itself. The end must be one of the primary design goals. Simplicity may thus sometimes be sacrificed for correctness, reliability and safety. '''Orthogonality''' of syntax is desirable when possible, but not at the expense of simplicity and clarity.

We followed the Einsteinian '''simplicity''' principle ''“as simple as possible, not any simpler.”'' but we did not elevate simplicity to the status of dogma. Simplicity is a means to an end, not an end of itself. The end must be one of the primary design goals. Simplicity may therefore sometimes be sacrificed for correctness, reliability and safety. '''Orthogonality''' of syntax is desirable when possible, but not at the expense of simplicity and clarity.

We followed the Einsteinian '''simplicity''' principle ''“as simple as possible, not any simpler.”'' but we did not elevate simplicity to the status of dogma. Simplicity is a means to an end, not an end of itself. The end must be one of the primary design goals. Simplicity may at times be sacrificed for correctness, reliability and safety. '''Orthogonality''' of syntax is desirable when possible, but not at the expense of simplicity and clarity.

* Suitability for mathematics and engineering.

* '''Prohibition of magic''', intuitive '''explicit syntax''' instead of magic implicit syntax.

* '''Modern''' — meet today’s programming requirements.

* '''Modern''' -- meet today’s programming requirements.

* '''Modern''', meet today’s programming requirements.

* '''Correctness''', '''Reliability''' and '''Safety''' may not be sacrificed.

* Suitability as a '''safe''' alternative to C in systems development.

!!!Primary Design Goals
* '''Revision''' of the language in the general context of today’s programming requirements.
* Following the Einsteinian '''simplicity''' principle ''“as simple as possible, not any simpler.”''
* Suitability as a '''safe''' alternative to C in systems implementation and systems programming.
* '''Clarity''' and '''maintainability''' of source code, specifically for readers other than the author.
* '''No magic''', intuitive '''explicit syntax''' is always preferable to magic implicit syntax.
* '''Orthogonality''' of syntax where possible, but not at the expense of simplicity and clarity.
* Non-interference of backwards compatibility concerns with any of the above principles.

!!!Feature Omission Guidelines

!!!Feature Addition Guidelines

!!!Backwards Compatibility Guidelines
If a certain practise is outdated, such as the use of octal numerals, then a feature that has no other use than to support that practise can no longer be justified and consequently we removed it without any regard for backwards compatibility of source code. Instead, a source to source translator tool should be seen as a suitable solution to backwards compatibility issues that arise from removal of outdated features.

* '''No Magic''', intuitive '''explicit syntax''' is always preferable to magic implicit syntax.