C-Aux

C-Aux family.

Extensions: .c (C or C-Aux), .cau (C-Aux or C\*Aux), \*.cpp (C++ or C+Aux), \*.cpau (C+Aux)

## C-Aux

C-Aux will be a C language variant.

It will be based on C, and aim for general compatibility, but not for strict standards conformance.

Features dropped from C (General):

* Trigraphs
	+ Trigraphs will be dropped
* Digraphs
	+ Digraph character sequences will be reserved
	+ However, they will no longer be interchangeable with normal braces.
* Bit-Fields
	+ May still be done manually
	+ Rarely used due to not being very useful.
	+ May be considered.
* K&R style declarations
	+ Only a newer ANSI style declarations may be used.
	+ Visible function declarations or prototypes are required.

C99 Features Not Included:

* VLAs
* \_Complex and \_Imaginary
	+ May be added later.
* various misc stuff.

Features added to C:

* "#pragma precompiled\_header" hint.
	+ Used as the first line in a header, indicates that the compiler should precompile this header.
	+ Unlike many other PCH mechanisms, C-Aux will ignore preceding headers
		- Each PCH will be compiled as-if it were standalone;
		- Multiple PCH headers may be used and in any order.
		- Headers will be use #include as normal.
* Load/JIT-time Ifdef/Define
	+ Explicit via \_\_ifdef(CC) and \_\_ifndef(CC)
	+ May be used implicitly by #ifdef or #ifndef with "magic #define's".
		- Unlike with normal #ifdefs, these will be required to obey proper brace nesting.
		- This is because this is a compile-time feature, not a syntax-feature.
		- It may not be used for conditional syntax, only for including/excluding declarations or code.
		- All code within the block is required to be syntactically valid.
	+ "#define\_arch CC" or "#define\_arch PP CC"
		- Will declare a JIT-time Define
		- When used with #ifdef or #ifndef, will indicate that this should be handled at JIT time.
		- Whether this block is present or not will depend on the VM.
		- Omitted blocks will be treated absent/no-op at run time.

Changes from C:

* Type Modifiers and Specifiers may exist.
	+ Modifiers will precede specifiers.
	+ If any number of specifiers are present, they will be assumed to declare the type
	+ Otherwise, the following non-keyword identifier will be assumed to be the type
	+ "modifier\* specifier+ declarator"
	+ "modifier\* typedef-name declarator"
* Unlike C, typedefs will not be relied on for declaration parsing.
	+ It will be parsed as a declaration if it matches the syntax for a declaration.
	+ This also applies to casts.
* Add modifier blocks: "modifier\* { ... }"
	+ Will apply modifiers to all declarations within the block.
* Add modifier labels: "modifier\*:"
	+ Will apply modifiers to all declarations until the end of the current block (and/or the next label).

Still unimplemented:

* Multidimensional array support;
* C99 style struct initializers.

### Keywords

Language Main Keywords

* auto
* break
* case
* char
* const
* continue
* default
* do
* double
* else
* enum
* extern
* float
* for
* goto
* if
* inline
* int
* long
* register
* restrict
* return
* short
* signed
* sizeof
* static
* struct
* switch
* typedef
* union
* unsigned
* void
* volatile
* while

### Declarations

Declaration:

* "modifier\* specifier+ declarator"
* "modifier\* typedef-name declarator"

Type Modifiers:

* extern
* static
* const
* inline
* \_\_const (alias for const)
* \_\_inline (alias for inline)
* \_\_forceinline (always inline)
* \_\_stdcall (Win32: uses Stdcall externally)
* \_\_cdecl (Uses cdecl / native ABI)
* \_\_proxy (Function is late-bound)
* \_\_ltlendian (Use little-endian storage)
* \_\_bigendian (Use big-endian storage)
* \_\_transient
* \_\_thread
* \_\_dynamic

Special Modifers / Attributes

* \_\_declspec(DD)
	+ DD is a comma separated list of attribute names, or names followed by parameters.
		- "\_\_declspec(foo)" or "\_\_declspec(foo, bar(3, 4), baz("test"))"
		- dllimport, specifies an import
		- dllexport, specifies an export

Type Specifiers:

* int
* long
* float
* double
* void
* char
* short
* auto
* \_\_int64
* \_\_uint64
* \_\_int128
	+ \_Int128
* \_\_uint128
* \_\_float128
	+ \_Float128
* \_\_float16
	+ \_Float16

Ambiguous Type Specifiers:

* signed
* unsigned

An ambiguous specifier will behave as a modifier if another type-specifier is present, but will otherwise function as a type-specifier.

As in normal C, structs, unions, or enums may be used in declarations.

Type Sizes:

* char / unsigned char, 8 bits
	+ char is a fixed-size type in C-Aux, only 8-bit chars are allowed.
* short / unsigned short, 16 bits
	+ likewise, short is a fixed 16 bit type
* int / unsigned int, 32 bits
* long / unsigned long, target specific
	+ If applicable, it will match the size of long in the native C ABI for a target
	+ Otherwise, long will default to 64 bits.
* long long / unsigned long long, 64 bits
* float, 32 bit IEEE binary32
* double, 64 bit IEEE binary64
	+ Unlike normal C, float and double are required to be the IEEE types.
* long double, treated as double
* short float, treated as \_\_float16 (IEEE binary16)
* pointers, target specific
* wchar\_t, will be 16-bit and use UTF-16 in C-Aux.

## C\*Aux (Possible)

Possible: Superset of C-Aux.

* *modifier\** **\_\_operator** *dtype* *op*(*stype a*, *ttyle b*): *func*(*a*, *b*);
	+ Overloaded Operator

* *modifier\** **\_\_class** *classname*:*superclass*,*interfacelist* { ... }
	+ Class Declaration.
	+ Will be single inheritance.

* *modifier\** **\_\_interface** *ifacename*:*superiface* { ... }
	+ Interface Declaration.

## C+Aux (Possible)

C+Aux will aim to be subset compatible with C++, however will not aim to fully implement C++.

it will be C-Aux with some C++ like additions:

* classes
	+ Will be (internally) restricted to single inheritance and "interfaces"
	+ Will not support member-pointers.
	+ C+Aux may mimic MI support to a limited extent.
		- Any secondary base-classes will be treated as interfaces.
* interfaces
	+ A special case of abstract classes
	+ May declare method bodies, however they will behave like default methods.
		- If the class declares a method, the one from the interface will be ignored.
	+ May provide named fields.
	+ All class contents will essentially merge, and calling methods via QNames will not be allowed.
		- Uncertain: Make diamond inheritance and similar work?
* namespaces
* operator overloading
* references
* (?) a constrained form of templates
	+ If-implemented, may only do simple type substitutions.

Like in C++, classes will be pass-by-value by default, and explicit pointers will be used.

Omissions from C++:

* named operators
* (?) special cast types
* C++ standard library

### Additional Keywords

* bool (type)
* catch (try/catch)
* class
* delete
* false
* friend (modifier)
* namespace
* new
* operator
* private
* protected
* public
* template
* this
* throw
* true
* try (try/catch)
* using
* virtual

### Namespace

```
//declare namespace
namespace ns_name {
  stuff...
}

//import symbols from namespace
using namespace ns_name;

//import a single declaration
using ns_name::name;

```

### Class

```
modifier* class name [ ':' superclass-list ] [ '{' class-body '}' ]

class Foo { ... };
abstract class IFoo { ... };
class Bar:Foo,IFoo { ... };

```

example in use:

```
class Foo {
  public:
  Foo() { /* constructor, do something */ }
  ~Foo() { /* destructor, do something */ }
  void doSomething();
};

void Foo::doSomething()
  { /* do something */ }

void someFunc()
{
  Foo *foo;
  foo=new Foo();
  foo->doSomething();
  delete foo;
}

```