New language features have a place in game code?

[WILL]

Getting this thread back on topic however, I am interested to see what kind of new language features that Oxygene will bring as it continues to evolve into it's very distinct language.

Is there a feature you would like to see added to any of the existing Pascal-based languages or dialects?

[Eric]

At the risk of starting another flame war, I would say some form of templates could be very useful. C++-like templates.

Generics are all fine and dandy when it comes to containers, but beyond those, they quickly become quite messy & unwieldy. Also they favor bloat-ware/code complexity on the generated binary, which isn't very desirable for games.

For games, the downsides of templates (weird, hard to understand compile-time errors) would matter much less than their benefits.

For those that don't know the difference, it can be summarized by saying that a generic can be syntax-checked on its own (outside of any specialization), while a template is closer to a macro, that is syntax-checked on specialization.

For instance, suppose you want to add two "things", with templates, you can write just:

function Add<T>(a, b : T) : T;
begin
   Result := a + b
end;

It'll work for Integer, String, Double, or anything for which you overloaded the + operator (like vector records/static arrays).
And you'll get an error for things that don't support the + operator, like Add<Boolean>.

But it won't work for generics, as a generic type T can't always be added... so you'll get a compile-time error on the generic.
To make it work, you have to add an interface and a constraint:

type IAddable<T> = interface
   function Add(b : T) : T;
end;

function Add<T : IAddable<T>>(a, b : T) : T;
begin
   Result := a.Add( b );
end;

but then it'll only work for generic classes that implement the generic IAddable interface, it won't work for simple types, records or arrays unless you box them.

It also makes a simple generic sorter a creation of hideous complexity, as you'll need a generic IComparer<T> (cf. the RTL source...), while writing a template-based sorter can be trivial. Same goes for most algorithms. Soon enough, you find yourself piling up generic interfaces.

Now, all isn't rosy with templates, as templates can use other templates, so it's possible to get at the specialization errors that relate to a sub-sub-sub-template of the template you're using, with an error message that can be eminently cryptic because it bears only very indirect relation to what you were trying to do.

[LP]

At the risk of starting another flame war, I would say some form of templates could be very useful. C++-like templates.

Generics are all fine and dandy when it comes to containers, but beyond those, they quickly become quite messy & unwieldy. Also they favor bloat-ware/code complexity on the generated binary, which isn't very desirable for games.

I think the Duck Typing concept that Jason mentioned at the beginning is similar to the templates that you are describing. Even though you sacrifice maintainability and readability for a more compact code, I think they could be much more useful than generics. Also, you can do some weird things with C++-like templates.

[Eric]

I think the Duck Typing concept that Jason mentioned at the beginning is similar to the templates that you are describing.

Not really, duck-typing is a form of implicit interfaces (and that's how Oxygene implements them under the hood btw), the C++ templates are more of a form of restricted macros, which can recursively reference each other.

Another aspect is that templates are (as far as C++ goes) fully resolved at compile-time, while duck-typing can often be resolved only at run-time. So duck-typing is usually tied to dynamic typing, and for strongly typed languages, it involves some form of RTTI.

[Mirage]

At the risk of starting another flame war, I would say some form of templates could be very useful. C++-like templates.
...
It also makes a simple generic sorter a creation of hideous complexity, as you'll need a generic IComparer<T> (cf. the RTL source...), while writing a template-based sorter can be trivial. Same goes for most algorithms. Soon enough, you find yourself piling up generic interfaces.

Now, all isn't rosy with templates, as templates can use other templates, so it's possible to get at the specialization errors that relate to a sub-sub-sub-template of the template you're using, with an error message that can be eminently cryptic because it bears only very indirect relation to what you were trying to do.

I wrote here about an include-based technique which can be used to create generic containers and algorithms.
For algorithms it works fine and is simple to use:

procedure Sort(Count: Integer; Data: array of TSortData);
  type
    _SortDataType = TSortData;
  const 
    // Algorithm compile-time options
    _SortOptions = [soDescending];

    // Optional comparator function needed if TSortData cannot be compared directly with "<" operator
    function _SortCompare(const V1,V2: TSortData): Integer; inline;
    begin
      Result := V1.Value - V2.Value;
    end;

    {$I gen_algo_sort.inc} // include type-independent sort implementation

  end;

I forgot to mention another useful feature of recent Delphi versions - full-blown RTTI.
It can be used for many things, including dynamic code update, when you can compile new version of, for example, character AI class and dynamically update it in application/editor to immediately test the new behaviour without even restarting a level.

[Eric]

I forgot to mention another useful feature of recent Delphi versions - full-blown RTTI.
It can be used for many things, including dynamic code update, when you can compile new version of, for example, character AI class and dynamically update it in application/editor to immediately test the new behaviour without even restarting a level.

You can, but that part is quite fragile when done through RTTI, not because of RTTI, but because of memory management and the RTL/VCL isn't safe, so it's very easy to end up with dangling pointers, memory leaks and memory overwrites. You need some severe sandboxing and safety to be able to edit & run things interactively, and RTTI doesn't provide that.