Tusk supports Delphi's string and AnsiString types, but not WideString (use string instead).

As in Delphi, Tusk strings are one-based, not zero-based. This applies even when accessing a string through an Any variable…

var s: string := 'hello'; Writeln(s[2]); // prints "e", not "l" var v: Any := s; Writeln(v[2]); // prints "e", not "l"

This also applies to standard RTL functions like Copy, Insert, and Delete…

var s: string := 'hello'; Writeln(Copy(s, 2, 2)); // prints "el", not "ll" var v: Any := s; Writeln(Copy(v, 2, 2)); // prints "el", not "ll"

Note that Delphi doesn't allow indexing into a string value through a Variant variable.

Tusk supports the + operator for concatenating dynamic arrays…

var a: TArray<Byte> := [1,2,3]; var b := a + [4,5,6];

Above, b is initialized to [1,2,3,4,5,6].

Tusk also supports Delphi's dynamic array constructor notation…

var x := TArray<Double>.Create(1, 2, 4.5);

In Delphi, when a dynamic array converted to Variant, it becomes a Variant array, which is very different from a Delphi-native dynamic array…

• Variant arrays use the COM memory manager, not Delphi's FastMM memory manager, resulting in noticeable performance degradation.
• Variant arrays are not reference-counted: every Variant array is a brand new copy of the data.
• Variant arrays may only contain OLE-compatible elements (integers, floats, WideString, Boolean, date/times, and interfaces). Specifically, Delphi records and sets are not supported.

For the above reasons, especially the last one, Tusk does not create a Variant array when converting a dynamic array to Variant. Instead, it uses a custom Variant type (defined in DSGenUtil) that can hold values of any Delphi data type. This is also how Tusk stores records, sets, and pointers.

Tusk does support Variant Arrays, when created explicitly via routines such as VarArrayCreate.

In Delphi, pointers are not memory-safe, opening programs up to issues such as buffer overflows and over-writes, dangling pointers, wild pointers, etc.

In Tusk, when you take the address of a variable (using the @ operator), the result points to a value that will be kept "alive" as long as the pointer survives.

For example…

function GetIntPtr: PInteger; var x: Integer; begin x := 123; Result := @x; end; var p: PInteger := GetIntPtr; Writeln(p^); Inc(p^); Writeln(p^);

The above program prints 123 followed by 124. In Delphi, this program exhibits a serious problem: GetIntPtr returns the address of a local variable, which ceases to exist once the function returns. This is not a problem for Tusk – the local variable x continues to exist until p no longer references it.

Additionally, Tusk includes runtime checks when using pointers. For example, revisiting the above code, suppose there's a bug…

var p: PInteger := GetIntPtr; Writeln(p^); Inc(p); // NOTE: should be Inc(p^), not Inc(p)! Writeln(p^);

This code is incrementing p, instead of incrementing p^. In Delphi, this causes the subsequent Writeln to print out some random/garbage value. In Tusk, however, the call to Inc(p) is a runtime error: Tusk knows that p doesn't point to an array or list, so incrementing it is not allowed.

Like Delphi, Tusk supports pointer math (addition and subtraction operations involving pointers). Unlike Delphi, pointer math is memory-safe in Tusk…

type PInteger = ^Integer; var a: TArray<Integer> := [1,2,3,4,5,6]; var p: PInteger; p := @a[0]; for var i := 0 to High(a) do begin Writeln(p^); Inc(p); end;

Tusk supports taking the address of a property…

var ls := NewStringList; var cs := @ls.CaseSensitive; ls.CaseSensitive := False; Writeln(cs^); // prints False ls.CaseSensitive := True; Writeln(cs^); // prints True cs^ := False; Writeln(ls.CaseSensitive); // prints False

As the example above demonstrates, a pointer to a property is an additional way to access the property's value. Above, the variable cs maintains a reference to the IStringList object, independent of the ls variable…

var ls := NewStringList; var cs := @ls.CaseSensitive; ls.CaseSensitive := False; Writeln(cs^); // prints False ls := NewStringList; // ls and cs diverge ls.CaseSensitive := True; Writeln(cs^); // prints False

Above, assigning a new value to ls causes ls and cs to no longer reference the same IStringList object.

When taking the address of a property in a record, the pointer maintains a reference to the variable that holds the record.

Tusk also supports taking the address of elements in an array property…

var b := NewPropBag; b['x'] := 'hello'; b['y'] := 'goodbye'; var p := @b['x']; Writeln(p^); // prints "hello' p^ := UpperCase(p^); Writeln(b['x']); // prints "HELLO"

The same idea applies to lists…

var ls := NewList(['hello', 3, True]); var p := @ls[1]; Writeln(p^); // prints 3 Inc(p^); Writeln(ls[1]); // prints 4

In the above example, Tusk understands that the IVector.Items property is array-like, so it allows pointer math on p…

var ls := NewList(['hello', 3, True]); var p := @ls[0]; Writeln(p^); // prints "hello" Inc(p); Writeln(p^); // prints 3 Writeln(p[1]); // prints True

Tusk only supports pointer math on specific array properties such as IVector.Items, but not others such as IAssociation.Values. In the Tusk RTL Documentation, you'll see such properties annotated with the [TuskArray] attribute (for example, scroll to the end of DSGenUtil.IVector).