It’s been a while since the last road map.

It’s been a while since the last road map.

Until the powers that be provide us a new one – what feature(s) would you like to see in the next Delphi city?

Some of my whimsical desires include…

– More fixes for known issues 

– Proper High DPI management built into VCL (multi DPI image lists, etc) and a proper overhaul for the IDE to rid it of scaling issues

– RTL performance improvements for generics and multithreaded memory management

– A default out-of-the box cross-platform exception stack tracer with API for plugging in enhanced custom stack tracers, information providers and logging mechanisms

– Code generation improvements utilising more modern CPU features

– Beacon/IoT support for VCL/Windows platform

Anonymous Method constraints

Anonymous Method constraints

Due to the occasional shooting of foot due to how capture works, I wish there was a way of optionally constraining references for an anonymous method, so that I could enforce local references only.

type

  TFilterMethod = constrained reference to function (const Item:T):Boolean;

  TInstanceList = class

    property function Filtered(Filter: TFilterMethod):TInstanceList;

  end;

var

  SomeRef: TQualifier;

  List: TInstanceList;

  Element: TThing;

begin

  …

  // compiles

  for Element in List.Filtered(function (Item: TThing)

    begin

      Result := Item.Qualifier in [This, That]);

    end)

  do begin

    …

  // should not compile – but error on “reference outside method not allowed for constrained methods

  for Element in List.Filtered(function (Item: TThing)

    begin 

      Result := (Item.Qualifier = SomeRef);

    end)

  do begin

    …

The Perils of Format

The Perils of Format

Format is good. Format is bad.

The good is that you can create very nice translatable strings which can deal with reordered parameters, and that perform fairly well.

if Language = Yoda

then fmt := ‘%1:s apples, %0:d you took.’

else fmt := ‘you took %0:d %1:s apples.’; // English

Writeln(Format(fmt, [5, ‘green’]));

So, what is the pain?  All the checks are done at run time.

Let me repeat that: … at run time.  

Once again, during a hotfix, I blew it on the parameter type, mistakenly passing a Double into the position where an Integer was expected.

I really wish that there was compiler magic that could validate the type and position of the Format parameters at compile time.  Until there is, I will be careful to send all parameters as strings, and convert to string in the Format argument list – at least for the quick fixes.

 

Type inference and inline declarations

Type inference and inline declarations

(Copied from a comment I wrote on Non-tech.)

I would like to see more scope fencing through inline declarations and automatic type inference.

for aItem in myList do if Pos( ‘widget’, aItem ) > 0 then listbox1.Items.Add( aItem ); 

aItem doesn’t really need a declaration if the list is a TList or in any other way expose a type through the default property.

Should I need to cast the type of an iteration variable, it could be done like: for aItem:String in myList – and still be possible to type check at compile time.

I think inline declaration would be very good for iterators – so that you don’t mix variable and iterator use – such as first using it in a for loop iteration and later reuse it as a reference variable.

Scope limited temporary variables would also be great. 

Alt.1

using A:TThisType, B:TThatType

begin

// The simple reference variables A and B only exists within this scope. 

end;

Alt.2

using auto A:TThisType, B:TThatType

begin

// A and B are created on entering and destroyed on exiting this scope. 

end;

And then there is the dreaded with statement which could be replaced by a type inferred reference

using A as Some.Object.List[Index]

begin

  // A only exists within this scope

  A.Value := ..

end

A would be typed from the list element type, and if you need a cast

using A:TSomeType as Some.Object.List[Index]

begin

  // A only exists within this scope

  A.Value := ..

end

That would also be type checkable at compile time.

Generics and enumerations

Generics and enumerations

We need a type qualifier for enumerated types that allow us to do loops and indexing with generic enumerables.

type

TMyType = (a, b, c);

TEnumToStr = reference to function(Value:T):String;

procedure SomeClass.ListTypes(ToString:TEnumToStr);

var

  v: T;

begin

  for v := Low(T) to High(T)  //<– Error

   do Writeln(ToString(T));

[dcc32 Error] : E2032 For loop control variable must have ordinal type

Argh!

Any suggestion to for a clever workaround?  I need to write tests for dozens of EnumToString functions for enumerable types, and would love to avoid having to recreate the entire loop with declarations, sanity checks, logging and all.