Recent changes to Syntax-Classes

Syntax-Classes modified by Ove Kåven

Ove Kåven — Sun, 25 Aug 2019 19:45:44 -0000

--- v31
+++ v32
@@ -4,25 +4,25 @@
 -------
 *Classes* are structures that can hold data fields, method implementations, and operator overloads. They support standard single-dispatch polymorphism, but multiple-dispatch will also be supported at some point. (It's not decided whether multiple dispatch should be automatic or enabled with a keyword.) Here's an example:

-    import "stdio", "glib";
-    using GLib;
+    import "stdio", "glib"
+    using GLib

     class Printer
     {
-      print(msg: CString) { stdout.printf(msg); }
-      virtual hello() { }
+      protected print(msg: CString) { stdout.printf(msg) }
+      public virtual hello() { }
     }

     class HelloPrinter: Printer
     {
-      override hello() { print("Hello World\n"); }
+      override hello() { print("Hello World\n") }
     }

     public main(): int
     {
-      printer: Printer = HelloPrinter();
-      printer.hello();
-      return 0;
+      printer: Printer = HelloPrinter()
+      printer.hello()
+      return 0
     }

 Classes are *reference types*, meaning instances of them are usually allocated on the heap, and passed by reference. Thus, they can continue to exist after leaving the code block they were created in.
@@ -48,23 +48,25 @@
 Even more useful, though, is the way a class hierarchy can use virtual metamethods to implement RTTI (Run-Time Type Information). For example:

     class base {
-      meta virtual get_name(): CString { @#owner }
+      public meta virtual get_name(): CString { @#owner }
     }

     class subclass: base {
-      do_something();
+      do_something()
     }

     ...
-    obj: base = subclass();
+    obj: base = subclass()

-Now, obj.get_name() will return the string "subclass". (Note that subclasses can still override metamethods by defining a method with the same name.)
+Now, `obj.get_name()` would return the string `"subclass".` (Note that subclasses can still override metamethods by defining a method with the same name.)

 Run-Time Type Information
 -------------------------
 Many class frameworks out there already have RTTI systems of their own, and therefore does not need the programming language to provide one. For example, the GObject framework (part of GLib) provides a powerful language-independent RTTI system (GType). Recognizing this, MORTAL assumes that class hierarchies that need polymorphism do implement their own RTTI, e.g. by using metamethods, or even defining a custom vtable.

-To provide RTTI, the classes must overload two operators: the "typeid" operator, and the "is" operator. (The language does not care what the "typeid" operator returns, but the corresponding "is" operator must accept whatever "typeid" returns.) If these operators are provided, the compiler will use them to ensure full run-time type safety (including dynamic casts, etc).
+To provide RTTI, classes must overload two operators: the `typeid` operator, and the `is` operator. (The language does not care what the `typeid` operator returns, but the corresponding `is` operator must accept whatever `typeid` returns.) At minimum, a static `typeid` and a non-static `is` should be defined, but for flexibility, it's also possible to overload a non-static `typeid` and a static `is`. The compiler will then choose the appropriate versions.
+
+Once these operators are defined by the class framework, the compiler will use them to ensure full run-time type safety and multiple dispatch features (including dynamic casts, exception catching, multimethods, etc).

 Constructors and Destructors
 ----------------------------
@@ -77,7 +79,7 @@
 - *Constructors* ("constructor()") are used to initialize a class instance. They are called after memory has already been allocated.
 - *Destructors* ("destructor()") are used to finalize a class instance. They are called before memory is freed.

-In MORTAL, constructors don't have to be filled with lots of assignments. If a constructor parameter and a class field has the same name, then an assignment between them is automatically generated. All other class fields are initialized to their default values (zero in the case of integers). You may not have to write anything yourself in the constructor body.
+In MORTAL, constructors don't have to be filled with lots of assignments. If a constructor parameter and a class field has the same name, then an assignment between them is automatically generated. All other class fields are initialized to their default values. You may not have to write a constructor body yourself.

 Transparent classes
 -------------------
@@ -95,8 +97,8 @@

     transparent class file: __c_ptr.FILE
     {
-      extern new(path: __c_ptr.char, mode: __c_ptr.char) => __c_lib.fopen;
-      extern delete() => __c_lib.fclose;
+      extern new(path: __c_ptr.char, mode: __c_ptr.char) => __c_lib.fopen
+      extern delete() => __c_lib.fclose
       ...
     }

@@ -107,19 +109,22 @@
 For example, GLib's linked list type is wrapped this way:

     transparent class ListNode<t>: __c_ptr.GList {
-      data: T => __c_lib.data;
-      next: ListNode<:T> => __c_lib.next;
-      prev: ListNode<:T> => __c_lib.prev;
+      data: T => __c_lib.data
+      next: ListNode<:T> => __c_lib.next
+      prev: unowned ListNode<:T> => __c_lib.prev
       ...
     }

     transparent struct List<t>
     {
-      content: ListNode<:T>;
-
-      empty(): bool { content == null }
+      content: ListNode<:T>
       ...
-      append(data: T) { content = __c_lib.g_list_append(content, data); }
+      static extern do_append<t>(list: ListNode<:T>?, persisted data: def_owned T): ListNode<:T>
+        => __c_lib.g_list_append
+      ...
+      empty: bool { get { content === null } }
+      ...
+      append(data: T) { content = do_list_append(content, data) }
       ...
     }

@@ -132,59 +137,59 @@
 Structs, classes, and interfaces can be parametrized. Two approaches can be used.

 *Generics with regular classes:*
-If regular classes are parametrized, they work much like Java generics, in the sense that the class implementation itself is typically unaware of the actual type stored, and treats it as a generic pointer.
+If regular classes are parametrized, they work much like Java generics, in the sense that the class implementation itself is typically unaware of the actual type stored ("type erasure"), and treats it as a generic pointer.

     class Container<t>
     {
-      stg: T;
-      set(d: T) { stg = d; }
+      stg: T
+      set(d: T) { stg = d }
       get(): T { stg }
     }

     public main(): int
     {
-      info: Container<:CString>();
-      info.set("Hello World\n");
-      stdout.printf(info.get());
-      return 0;
+      info: Container<:CString>()
+      info.set("Hello World\n")
+      stdout.printf(info.get())
+      return 0
     }

 In this case, only the caller (main) knows what actual type is stored in the container. The class may, however, constrain what types can be stored.

-- "class Container<t\>" means that T can be any type.
-- "class Container<class t\="">" means that T can be any class (not a struct). Similar syntax works for structs. These count as partial specializations.
-- "class Container<t: base\="">" means that T can be some subclass of base. It can be combined with the above, if desired. This counts as a partial specialization.
-- "class Container<:int\>" means that this is a full specialization (in this case, for integers). (This is also the syntax used for instantiating a generic type.)
+- `class Container<t>` means that T can be any type.
+- `class Container<class t="">` means that T can be any class (not a struct). Similar syntax works for structs and interfaces. These count as partial specializations.
+- `class Container<t: base="">` means that T can be some subclass of base. It can be combined with the above, if desired. This counts as a partial specialization.
+- `class Container<:int>` means that this is a full specialization (in this case, for integers). (This is also the syntax used for instantiating a generic type.)

 If the class needs more information about the type, it's possible to add implicit parameters to its constructor, possibly taking advantage of RTTI. Such implicit arguments are evaluated while the type is still known, and can then be stored in the class.

     class Container<t>
     {
-      delegate Destroyer(obj: T);
+      static delegate Destroyer(obj: T)

-      stg: T;
-      type: Type;
-      destroy: Destroyer;
+      stg: T
+      type: Type
+      destroy: Destroyer

       constructor(implicit type: Type = typeid(T),
-                  implicit destroy: Destroyer = T.delete);
-      destructor() { destroy(stg); }
-      set(d: T) { stg = d; }
+                  implicit destroy: Destroyer = T.delete)
+      destructor() { destroy(stg) }
+      set(d: T) { stg = d }
       get(): T { stg }
     }

-Now, the "type" field has the RTTI information for the stored type, and "destroy" has the type's deallocator. That way, if you destroy the container, its destructor can make sure the stored object itself is also destroyed.
+Now, the `type` field has the RTTI information for the stored type (assuming its `typeid` operator returns an object of type `Type`), and `destroy` has the type's deallocator. That way, if you destroy the container, its destructor can make sure the stored object itself is also destroyed.

 *Generics with transparent structs:*
 Should you need something more along the lines of C++ templates, then you can write your container as a parametrized mixin. You can then subclass it for the types you need. (Because implementing a container for each type is done explicitly, the compiler can always be sure in which module to place the code for that type.) You can combine this technique with partial specialization to minimize the number of implementations you need.

     transparent struct ContainerTemplate<t>
     {
-      stg: T;
-      set(d: T) { stg = d; }
+      stg: T
+      set(d: T) { stg = d }
       get(): T { stg }
     }

-    class Container<:int>: ContainerTemplate<:int>;
-    class Container<:bool>: ContainerTemplate<:bool>;
-    class Container<class t="">: ContainerTemplate<t>; // all reference types
+    class Container<:int>: ContainerTemplate<:int>
+    class Container<:bool>: ContainerTemplate<:bool>
+    class Container<class t="">: ContainerTemplate<t> // all reference types
</t></class></t></class></t></t></t:></class></t></t:></class></t\></t></t></t></t>

Syntax-Classes modified by Ove Kåven

Ove Kåven — Tue, 04 Mar 2014 15:07:02 -0000

--- v30
+++ v31
@@ -48,7 +48,7 @@
 Even more useful, though, is the way a class hierarchy can use virtual metamethods to implement RTTI (Run-Time Type Information). For example:

     class base {
-      meta virtual get_name(): cstring { @class_name }
+      meta virtual get_name(): CString { @#owner }
     }

     class subclass: base {

Syntax-Classes modified by Ove Kåven

Ove Kåven — Tue, 04 Mar 2014 15:04:53 -0000

--- v29
+++ v30
@@ -2,13 +2,14 @@

 Classes
 -------
-Classes are structures that can hold data fields, method implementations, and operator overloads. They support standard single-dispatch polymorphism, but multiple-dispatch will also be supported at some point. (It's not decided whether multiple dispatch should be automatic or enabled with a keyword.) Here's an example:
+*Classes* are structures that can hold data fields, method implementations, and operator overloads. They support standard single-dispatch polymorphism, but multiple-dispatch will also be supported at some point. (It's not decided whether multiple dispatch should be automatic or enabled with a keyword.) Here's an example:

-    import "stdio";
+    import "stdio", "glib";
+    using GLib;

     class Printer
     {
-      print(msg: cstring) { stdout.printf(msg); }
+      print(msg: CString) { stdout.printf(msg); }
       virtual hello() { }
     }

@@ -30,9 +31,9 @@

 Structs
 -------
-Structs are data structures meant to hold a fixed set of data fields. Structs can also define methods and operators. However, structs are not full classes. While they can inherit, they are not polymorphic and cannot have virtual methods.
+*Structs* are data structures meant to hold a fixed set of data fields. Structs can also define methods and operators. However, structs are not full classes. While they can inherit, they are not polymorphic and cannot have virtual methods.

-Structs are *value types*, meaning instances of them are usually allocated on the stack, and passed by value (copied). They are, therefore, mostly useful for small (and perhaps short-lived) objects, such as numbers or iterators. Since they are allocated on the stack, they are automatically destroyed when leaving the code block they were created in.
+Structs are *value types*, meaning instances of them are usually allocated on the stack, and passed by value (copied). They are, therefore, mostly useful for small (and perhaps short-lived) objects, such as numbers or iterators. When allocated on the stack, they are automatically destroyed when leaving the code block they were created in.

 Interfaces
 ----------
@@ -47,17 +48,17 @@
 Even more useful, though, is the way a class hierarchy can use virtual metamethods to implement RTTI (Run-Time Type Information). For example:

     class base {
-      meta virtual get_name(): cstring { return @class_name; }
+      meta virtual get_name(): cstring { @class_name }
     }

     class subclass: base {
-      void do_something() {}
+      do_something();
     }

     ...
     obj: base = subclass();

-Now, obj.get_name() will return "subclass". (Note that subclasses can still override metamethods by defining a method with the same name.)
+Now, obj.get_name() will return the string "subclass". (Note that subclasses can still override metamethods by defining a method with the same name.)

 Run-Time Type Information
 -------------------------
@@ -116,7 +117,7 @@
     {
       content: ListNode<:T>;

-      empty(): bool { return content == null; }
+      empty(): bool { content == null }
       ...
       append(data: T) { content = __c_lib.g_list_append(content, data); }
       ...
@@ -137,12 +138,12 @@
     {
       stg: T;
       set(d: T) { stg = d; }
-      get(): T { return stg; }
+      get(): T { stg }
     }

     public main(): int
     {
-      info: Container<:cstring>();
+      info: Container<:CString>();
       info.set("Hello World\n");
       stdout.printf(info.get());
       return 0;
@@ -155,7 +156,7 @@
 - "class Container" means that T can be some subclass of base. It can be combined with the above, if desired. This counts as a partial specialization.
 - "class Container<:int\>" means that this is a full specialization (in this case, for integers). (This is also the syntax used for instantiating a generic type.)

-If the class needs more information about the type, it can add implicit parameters to its constructor, possibly taking advantage of RTTI. Such implicit arguments are evaluated while the type is still known, and can then be stored in the class.
+If the class needs more information about the type, it's possible to add implicit parameters to its constructor, possibly taking advantage of RTTI. Such implicit arguments are evaluated while the type is still known, and can then be stored in the class.

     class Container
     {
@@ -169,7 +170,7 @@
                   implicit destroy: Destroyer = T.delete);
       destructor() { destroy(stg); }
       set(d: T) { stg = d; }
-      get(): T { return stg; }
+      get(): T { stg }
     }

 Now, the "type" field has the RTTI information for the stored type, and "destroy" has the type's deallocator. That way, if you destroy the container, its destructor can make sure the stored object itself is also destroyed.
@@ -181,7 +182,7 @@
     {
       stg: T;
       set(d: T) { stg = d; }
-      get(): T { return stg; }
+      get(): T { stg }
     }

     class Container<:int>: ContainerTemplate<:int>;

Syntax-Classes modified by Ove Kåven

Ove Kåven — Fri, 16 Aug 2013 17:39:18 -0000

--- v28
+++ v29
@@ -1,3 +1,5 @@
+[TOC]
+
 Classes
 -------
 Classes are structures that can hold data fields, method implementations, and operator overloads. They support standard single-dispatch polymorphism, but multiple-dispatch will also be supported at some point. (It's not decided whether multiple dispatch should be automatic or enabled with a keyword.) Here's an example:

Syntax-Classes modified by Ove Kåven

Ove Kåven — Fri, 16 Aug 2013 16:24:23 -0000

--- v27
+++ v28
@@ -38,7 +38,7 @@

 Metamethods
 -----------
-To complement traditional method inheritance, M.O.R.T.A.L. has *metamethods*. Traditional inheritance allows a subclass to use a method that was built for a base class. Metamethods, on the other hand, rebuilds the method for the subclass. That is, a separate implementation of that method is generated and compiled for every subclass in the class hierarchy.
+To complement traditional method inheritance, MORTAL has *metamethods*. Traditional inheritance allows a subclass to use a method that was built for a base class. Metamethods, on the other hand, rebuilds the method for the subclass. That is, a separate implementation of that method is generated and compiled for every subclass in the class hierarchy.

 While this feature should probably be used sparingly to avoid code bloat, it's very useful for certain things. The simplest use would be for implementing a generic algorithm that can be specialized by subclasses through overriding methods, but the overridden methods don't have to be virtual. They can even be static. This means the resulting code is faster.

@@ -59,13 +59,13 @@

 Run-Time Type Information
 -------------------------
-Many class frameworks out there already have RTTI systems of their own, and therefore does not need the programming language to provide one. For example, the GObject framework (part of GLib) provides a powerful language-independent RTTI system (GType). Recognizing this, M.O.R.T.A.L. assumes that class hierarchies that need polymorphism do implement their own RTTI, e.g. by using metamethods, or even defining a custom vtable.
+Many class frameworks out there already have RTTI systems of their own, and therefore does not need the programming language to provide one. For example, the GObject framework (part of GLib) provides a powerful language-independent RTTI system (GType). Recognizing this, MORTAL assumes that class hierarchies that need polymorphism do implement their own RTTI, e.g. by using metamethods, or even defining a custom vtable.

 To provide RTTI, the classes must overload two operators: the "typeid" operator, and the "is" operator. (The language does not care what the "typeid" operator returns, but the corresponding "is" operator must accept whatever "typeid" returns.) If these operators are provided, the compiler will use them to ensure full run-time type safety (including dynamic casts, etc).

 Constructors and Destructors
 ----------------------------
-While languages like C++ provide constructors and destructors, M.O.R.T.A.L. also provides allocators and deallocators, and even class initializers and deinitializers. Their roles are:
+While languages like C++ provide constructors and destructors, MORTAL also provides allocators and deallocators, and even class initializers and deinitializers. Their roles are:

 - *Initializers* ("initializer()") are executed on program startup. They can be used to register classes in a class factory, for example. (Especially useful if the initializers are also metamethods.)
 - *Deinitializers* ("deinitializer()") are executed on program shutdown.
@@ -74,7 +74,7 @@
 - *Constructors* ("constructor()") are used to initialize a class instance. They are called after memory has already been allocated.
 - *Destructors* ("destructor()") are used to finalize a class instance. They are called before memory is freed.

-In M.O.R.T.A.L., constructors don't have to be filled with lots of assignments. If a constructor parameter and a class field has the same name, then an assignment between them is automatically generated. All other class fields are initialized to their default values (zero in the case of integers). You may not have to write anything yourself in the constructor body.
+In MORTAL, constructors don't have to be filled with lots of assignments. If a constructor parameter and a class field has the same name, then an assignment between them is automatically generated. All other class fields are initialized to their default values (zero in the case of integers). You may not have to write anything yourself in the constructor body.

 Transparent classes
 -------------------

Syntax-Classes modified by Ove Kåven

Ove Kåven — Fri, 16 Aug 2013 16:17:39 -0000

--- v26
+++ v27
@@ -1,6 +1,26 @@
 Classes
 -------
-Classes are structures that can hold data fields, method implementations, and operator overloads. They support standard single-dispatch polymorphism, but multiple-dispatch will also be supported at some point. (It's not decided whether multiple dispatch should be automatic or enabled with a keyword.)
+Classes are structures that can hold data fields, method implementations, and operator overloads. They support standard single-dispatch polymorphism, but multiple-dispatch will also be supported at some point. (It's not decided whether multiple dispatch should be automatic or enabled with a keyword.) Here's an example:
+
+    import "stdio";
+
+    class Printer
+    {
+      print(msg: cstring) { stdout.printf(msg); }
+      virtual hello() { }
+    }
+
+    class HelloPrinter: Printer
+    {
+      override hello() { print("Hello World\n"); }
+    }
+
+    public main(): int
+    {
+      printer: Printer = HelloPrinter();
+      printer.hello();
+      return 0;
+    }

 Classes are *reference types*, meaning instances of them are usually allocated on the heap, and passed by reference. Thus, they can continue to exist after leaving the code block they were created in.

Syntax-Classes modified by Ove Kåven

Ove Kåven — Fri, 16 Aug 2013 13:23:13 -0000

--- v25
+++ v26
@@ -153,7 +153,7 @@
 Now, the "type" field has the RTTI information for the stored type, and "destroy" has the type's deallocator. That way, if you destroy the container, its destructor can make sure the stored object itself is also destroyed.

 *Generics with transparent structs:*
-Should you need something more along the lines of C++ templates, then you can write your container as a parametrized mixin. You can then subclass it for the types you need.
+Should you need something more along the lines of C++ templates, then you can write your container as a parametrized mixin. You can then subclass it for the types you need. (Because implementing a container for each type is done explicitly, the compiler can always be sure in which module to place the code for that type.) You can combine this technique with partial specialization to minimize the number of implementations you need.

     transparent struct ContainerTemplate
     {
@@ -164,3 +164,4 @@

     class Container<:int>: ContainerTemplate<:int>;
     class Container<:bool>: ContainerTemplate<:bool>;
+    class Container: ContainerTemplate; // all reference types

Syntax-Classes modified by Ove Kåven

Ove Kåven — Fri, 16 Aug 2013 12:58:32 -0000

--- v24
+++ v25
@@ -11,6 +11,10 @@
 Structs are data structures meant to hold a fixed set of data fields. Structs can also define methods and operators. However, structs are not full classes. While they can inherit, they are not polymorphic and cannot have virtual methods.

 Structs are *value types*, meaning instances of them are usually allocated on the stack, and passed by value (copied). They are, therefore, mostly useful for small (and perhaps short-lived) objects, such as numbers or iterators. Since they are allocated on the stack, they are automatically destroyed when leaving the code block they were created in.
+
+Interfaces
+----------
+Interfaces are a special kind of abstract (non-instantiable) class. They can contain method declarations, but not method implementations or data fields. Interfaces help avoid some of the problems and ambiguities that occur with multiple inheritance, since nothing is inherited from interfaces.

 Metamethods
 -----------
@@ -52,58 +56,11 @@

 In M.O.R.T.A.L., constructors don't have to be filled with lots of assignments. If a constructor parameter and a class field has the same name, then an assignment between them is automatically generated. All other class fields are initialized to their default values (zero in the case of integers). You may not have to write anything yourself in the constructor body.

-Generics
---------
-Structs and classes can be parametrized. In this case, they work much like Java generics, in the sense that the class implementation itself is unaware of the actual type stored, and treats it as a generic pointer.
-
-    class Container
-    {
-      stg: T;
-      set(d: T) { stg = d; }
-      get(): T { return stg; }
-    }
-
-    public main(): int
-    {
-      info: Container<:cstring>();
-      info.set("Hello World\n");
-      stdout.printf(info.get());
-      return 0;
-    }
-
-In this case, only the caller (main) knows what actual type is stored in the container (unless the class is transparent (see below), in which case the substituted implementation would see the actual type).
-
-Different kinds of parameters can be given, for example:
-
-- "class Container" means that T can be any type.
-- "class Container" means that T can be any class (not a struct). Similar syntax works for structs. These count as partial specializations.
-- "class Container" means that T can be some subclass of base. It can be combined with the above, if desired. This counts as a partial specialization.
-- "class Container<:int\>" means that this is a full specialization (in this case, for integers). (This is also the syntax used for instantiating a generic type.)
-
-*Under consideration:* The class could be made aware of what it's storing with a trick. It can define a constructor with default and/or implicit arguments, possibly taking advantage of RTTI. The implicit arguments are evaluated while the type is still known, so the results from their evaluation can be brought into the class.
-
-    class Container
-    {
-      delegate Destroyer(obj: T);
-
-      stg: T;
-      type: Type;
-      destroy: Destroyer;
-
-      constructor(implicit type: Type = typeid(T),
-                  implicit destroy: Destroyer = T.delete);
-      destructor() { destroy(stg); }
-      set(d: T) { stg = d; }
-      get(): T { return stg; }
-    }
-
-Now, the "type" field has the RTTI information for the stored type, and "destroy" has the type's deallocator. That way, if you destroy the container, its destructor can make sure the stored object itself is also destroyed.
-
 Transparent classes
 -------------------
-Structs and classes can be *transparent*. Transparent structs and classes are designed mostly for integrating with external libraries, but their features may also make them useful on their own.
+Structs and classes can be *transparent*. Transparent structs and classes are designed mostly for integrating with external libraries, but their features also make them useful on their own.

-Transparent classes are meant as "invisible" wrappers for some other feature. They are a bit like macros - in the source code, you use them like they're regular classes, but in the generated code, all method and operator calls are substituted with the implementation given in the class. That is, in the generated code the class doesn't exist, and it's like you wrote native code for the underlying feature directly.
+Transparent classes may be used as "invisible" wrappers for some other feature. They are a bit like macros - in the source code, you use them like they're regular classes, but in the generated code, all method and operator calls are substituted with the implementation given in the class. That is, in the generated code the class doesn't exist, and it's like you wrote native code for the underlying feature directly.

 This means that transparent classes have no runtime overhead, and that they reduce dependence on runtime libraries. (It might even be possible to write a platform-independent GUI framework using transparent classes and some metaprogramming, and have programs using it compile directly to native platform-specific GUI code - thus running faster and using less memory than if the framework used a runtime library.)

@@ -144,3 +101,66 @@
     }

 This makes linked lists easier to use and more consistent with other container types. Again, in the generated code, it's like you used GList directly.
+
+If a regular class derives from a transparent class/struct, then all the methods in it will be substituted into the subclass. Thus, transparent structs can also be used as *mixins*.
+
+Generics
+--------
+Structs, classes, and interfaces can be parametrized. Two approaches can be used.
+
+*Generics with regular classes:*
+If regular classes are parametrized, they work much like Java generics, in the sense that the class implementation itself is typically unaware of the actual type stored, and treats it as a generic pointer.
+
+    class Container
+    {
+      stg: T;
+      set(d: T) { stg = d; }
+      get(): T { return stg; }
+    }
+
+    public main(): int
+    {
+      info: Container<:cstring>();
+      info.set("Hello World\n");
+      stdout.printf(info.get());
+      return 0;
+    }
+
+In this case, only the caller (main) knows what actual type is stored in the container. The class may, however, constrain what types can be stored.
+
+- "class Container" means that T can be any type.
+- "class Container" means that T can be any class (not a struct). Similar syntax works for structs. These count as partial specializations.
+- "class Container" means that T can be some subclass of base. It can be combined with the above, if desired. This counts as a partial specialization.
+- "class Container<:int\>" means that this is a full specialization (in this case, for integers). (This is also the syntax used for instantiating a generic type.)
+
+If the class needs more information about the type, it can add implicit parameters to its constructor, possibly taking advantage of RTTI. Such implicit arguments are evaluated while the type is still known, and can then be stored in the class.
+
+    class Container
+    {
+      delegate Destroyer(obj: T);
+
+      stg: T;
+      type: Type;
+      destroy: Destroyer;
+
+      constructor(implicit type: Type = typeid(T),
+                  implicit destroy: Destroyer = T.delete);
+      destructor() { destroy(stg); }
+      set(d: T) { stg = d; }
+      get(): T { return stg; }
+    }
+
+Now, the "type" field has the RTTI information for the stored type, and "destroy" has the type's deallocator. That way, if you destroy the container, its destructor can make sure the stored object itself is also destroyed.
+
+*Generics with transparent structs:*
+Should you need something more along the lines of C++ templates, then you can write your container as a parametrized mixin. You can then subclass it for the types you need.
+
+    transparent struct ContainerTemplate
+    {
+      stg: T;
+      set(d: T) { stg = d; }
+      get(): T { return stg; }
+    }
+
+    class Container<:int>: ContainerTemplate<:int>;
+    class Container<:bool>: ContainerTemplate<:bool>;

Syntax-Classes modified by Ove Kåven

Ove Kåven — Tue, 13 Aug 2013 16:13:23 -0000

--- v23
+++ v24
@@ -63,7 +63,7 @@
       get(): T { return stg; }
     }

-    main(): int
+    public main(): int
     {
       info: Container<:cstring>();
       info.set("Hello World\n");

Syntax-Classes modified by Ove Kåven

Ove Kåven — Mon, 12 Aug 2013 11:06:04 -0000

--- v22
+++ v23
@@ -122,7 +122,7 @@

 It does not have to define any data member, if it's supposed to be an opaque type. All that matters to the compiler is that it's a pointer, and it has methods. In the generated code, it's like you used the FILE type directly, just like native C code would.

-*Those that do not inherit from something.* These must be structs, not classes, and are internally known as transcomplexes. The biggest difference from a regular struct is the substitution. If used as a local variable, each struct member is treated as a separate variable (thus, they may not be contiguous in memory). If passed to a function, each member is passed as a separate argument.
+*Those that do not inherit from something.* These must be structs, not classes, and are internally known as *transcomplexes*. The biggest difference from a regular struct is the substitution. If used as a local variable, each struct member is treated as a separate variable (thus, they may not be contiguous in memory). If passed to a function, each member is passed as a separate argument.

 For example, GLib's linked list type is wrapped this way: