I had another idea and I was just curious what anyone thought about it. Between C++ where classes can either be on the stack or heap and full ARC like in Swift/Java FPC is kind of in the middle with a unified heap-only class system which is easier to use than C++ (classes are always pointers so need to worry about pointer indirection all the time) but creates lots of garbage memory you need to manage yourself (no ARC/garbage collector unless you count ref counted interfaces).

My idea is to keep the FPC class as is but introduce a keyword that allocates the classes memory on the stack upon declaration. Then we you call Create like you normally would, instead of getting a new chunk of memory from GetMem the class internally references the pointer on the stack. Finally when the scope terminates it calls the destructor in a recursive process on all local variables (or class members) that are stack alias.

The benefits are:

1) Easy to implement since it just overrides GetMem with another pointer
2) Transparent to switch between heap vs stack since the class is always a pointer so no copying on pas and, pointer indirection, like c++ classes on the stack or Objects in Pascal (objects are missing features anyways and allocating on the stack still uses new() ). FPC is even worse than C++ in this regard because switching between class vs object is a real mess and just not practical.
3) More performant since we don’t need to allocate memory on the heap which we already know will be needed at compile time anyways. Doesn't require a runtime for garbage collecting and doesn’t allocate memory on the heap behind the scenes like Swift and full ARC systems probably do.

What do you think? Is there any merit to this idea? It’s not real reference counting but it’s a simple solution to improve performance and clean up code in many common scenarios.

type
	TMyClass = class
		child: TObject; stackalias;
		constructor Create; override;
		destructor Destroy; override;
	end;
constructor TMyClass.Create;
begin
	child := TObject.Create;
end;
destructor TMyClass.Destroy;
begin
	// all stack alias members call destructor here
end;
var
	parent: TMyClass; stackalias; // memory is reserved on the stack for sizeof(TMyClass)
begin
	parent := TMyClass.Create; // constructor still works like normal but internal pointer points to @parent
	// all stack alias local variables call destructor at end of scope
end;

Regards,
Ryan Joseph

Ryan Joseph schrieb am Mi., 25. Apr. 2018,
03:46:

What do you think? Is there any merit to this idea? It’s not real reference counting but it’s a simple solution to improve performance and clean up code in many common scenarios.

No. This would more often than not lead to accidents were users pass such an instance to some outer code (it doesn't even need to the routine with the stack object, but some third party routine that for some reason stores the pointer and is called from that routine) and then will trigger an exception in the best case or hard to debug errors in the worst case.

The memory model of classes in Object Pascal is heap based. Changing that is asking for trouble and I for one don't even want to fiddle around with that, because I don't see any real benefit in it (and yes I daily work with C++) that couldn't also be solved with a working ARC system.

Regards,
Sven

On Apr 25, 2018, at 12:59 PM, Sven Barth via fpc-pascal wrote: No. This would more often than not lead to accidents were users pass such an instance to some outer code (it doesn't even need to the routine with the stack object, but some third party routine that for some reason stores the pointer and is called from that routine) and then will trigger an exception in the best case or hard to debug errors in the worst case.

I assume if programmers care enough about performance they’re planning out memory usage by stack vs heap they know not to do that. The pointer is only alive for the duration of the scope. I thought this was a good idea because it explicitly lets you opt in when know you really need it and it’s discreet.

If c++ programmers know not to do that why don’t Pascal programmers? There’s endless ways to screw yourself with memory in general (especially in c++) but we still find a way.

The memory model of classes in Object Pascal is heap based. Changing that is asking for trouble and I for one don't even want to fiddle around with that, because I don't see any real benefit in it (and yes I daily work with C++) that couldn't also be solved with a working ARC system.

But putting classes on the stack is a core feature which is very well used and great for performance (why people still use c++ for games). Why isn’t that useful? So many of the stupid memory management patterns we use in Pascal could be replaced if the language had some good support for it. C++ does it and on the other end ARC languages do it for you, albeit at a performance loss.

Maybe I don’t know who the market for Pascal is anymore because to me it seems like a legacy language which is being kept alive by a small group of hobbyist but never actually used for any real world applications. I’ve already pretty much given up writing Mac apps with Pascal because it’s so hard to keep up to date and Swift is better than Objective-C but I’d like to keep using it for games if I can. At the end of the day I really want to be able to say at least Pascal is a good low-level language for writing fast code but in the face of C++ that’s kind of dubious claim.

Regards,
Ryan Joseph

On Apr 25, 2018, at 12:59 PM, Sven Barth via fpc-pascal wrote: The memory model of classes in Object Pascal is heap based. Changing that is asking for trouble and I for one don't even want to fiddle around with that, because I don't see any real benefit in it (and yes I daily work with C++) that couldn't also be solved with a working ARC system.

Just for fun here’s that same code from the previous post but with the keyword added. :) It’s really a good example because this is the same thing we do over and over again every day so it’s a perfect candidate for a simple compiler optimization. We save a block of code, not forgetting to call free and 2 pointers from GemMem that wasted CPU and got us closer to a fragmented heap.

It’s minor but it’s saves minor amounts of time and CPU cycles, both of which really add up over the lifetime of a program.

The programer in this case knows with 100% certainty they don’t need 2 pointers from GetMem but Pascal forces us anyways, and then makes us clean up the mess we didn’t need to make in the first place.

PS. I’m aware those 2 functions may actually raise exceptions but pretend they didn’t and this was just common memory management we do every day.

new code:

function TBlowFishCripto.Encrypt(const Value: string): string;
var
  en: TBlowFishEncryptStream; stackalias;
  stream: TStringStream; stackalias;
begin
  if length(Value) = 0 then
  begin
    Result := '';
    Exit;
  end;
  stream := TStringStream.Create('');
  en := TBlowFishEncryptStream.Create(FKey, stream);
  en.Write(Value[1], Length(Value));
  Result := stream.DataString;
end;

original code:

function TBlowFishCripto.Encrypt(const Value: string): string;
var
  en: TBlowFishEncryptStream;
  stream: TStringStream;
begin
  if length(Value) = 0 then
  begin
    Result := '';
    Exit;
  end;
  try
    stream := TStringStream.Create('');
    en := TBlowFishEncryptStream.Create(FKey, stream);
    en.Write(Value[1], Length(Value));
    Result := stream.DataString;
  finally
    FreeAndNil(en);
    FreeAndNil(stream);
  end;
end;

Regards,
Ryan Joseph

In our previous episode, Ryan Joseph said:

But putting classes on the stack is a core feature which is very well used and great for performance (why people still use c++ for games). Why isn?t that useful?

Most seem to be covered already by having records-with-methods. The only issue is that it is a different kind of "object".

So many of the stupid memory management patterns we use in Pascal could be replaced if the language had some good support for it. C++ does it and on the other end ARC languages do it for you, albeit at a performance loss.

I think if you want to pursue this, you must be much more concrete. Both the benefits and the potential pitfalls.

Maybe I don?t know who the market for Pascal is anymore because to me it seems like a legacy language which is being kept alive by a small group of hobbyist but never actually used for any real world application

This is patently false. Both Delphi and FPC are used professionally.

The dubious claim is the suggestion that detail language features are the main cause for language uptake. It isn't.

On Apr 25, 2018, at 3:22 PM, Marco van de Voort wrote: Most seem to be covered already by having records-with-methods. The only issue is that it is a different kind of "object”.

I like C++ because because you opt into stack or heap at any point. If you use a record then you’re stuck with a record. Objects are the better option but they’ve been neglected (missing interfaces amongst others) and the calling conventions are not the same (using new for example).

Look at the little code snippet I just posted using code from another post. It’s a good example of the kind of pattern I wanted to optimize. It’s save a little block of code and a call to GetMem which is good considering how little effort goes into the keyword. In functions called from tight loops it’s actually a big save.

Good news. :) That’s how it feels to me though. People are honestly confused when you tell them you use Pascal in 2018. I can’t point to where it’s a good low-language but then they remind of c++!

True. Pascal is basically dead on Mac because Apple has made it so hard to access their system frameworks. I made a parser to convert objective-c to Objective Pascal but it’s such a hassle to keep updated and Swift is replacing Objective-C anyways. Developers tools are hard to use outside of Xcode also.

Regards,
Ryan Joseph

On Apr 25, 2018, at 3:22 PM, Marco van de Voort wrote: I think if you want to pursue this, you must be much more concrete. Both the benefits and the potential pitfalls.

What are the potential pitfalls? Sven pointed out passing around pointers but don’t we know better than this since we’re using Pascal and know how memory works? If a function takes a class as a parameter don’t you know if the function is going to store it for later or not? Even if the class is on the heap I don’t just pass it another function and then forget about (creating a leak) or clean it up immediately because I think the function owns it now.

It’s basically like doing this right? I do this often to prevent copying but I just learned this year about the “constref” keyword which cleans up the @ symbol (another small optimization which I really appreciate being added).

var
  rec: TSomeRec;
begin
  DoThis(@rec);
end;

I know DoThis isn’t going to keep the pointer alive for later or I would never do this. Since the keyword is an explicit opt-in I assume the programmer really does know they’re doing because they are 100% certain they want the class to only exist for the lifetime of the scope.

In fact adding the keyword is like an explicit contract to the compiler that you INSIST the class be destroyed at the end of the scope. That’s the entire purpose of it, eg. “kill me at the end of scope so I don’t have to do this myself later”. :) If the programmer was smart enough to tell the compiler that we can assume they won’t be stupid and pass it around to some random function they don’t trust.

Regards,
Ryan Joseph

If you know what you are doing, you have exactly the "object" type for that. You can allocate them on the stack or heap and you can inherit from them, when you need virtual methods the initialization is a bit strange (and if you need performance virtual methods are wrong anyway). The benefit is better performance when needed. The downside is that they are more unsafe to use than "class" type and you should now what you do. If I need a cheap (performance wise) "procedure of object" for example, that can't escape from the scope I use them instead of a class:

type
  TDataArray = array of Integer;
  TFilterData = function(element: Integer): Boolean of object;
function FilterData(const data: array of Integer; filter: TFilterData):
TDataArray;
var
  i, lr, el: Integer;
begin
  Result:= nil;
  lr:= 0;
  for el in data do begin
    if filter(el) then begin
      SetLength(result, lr + 1);
      result[lr]:= el;
      inc(lr);
    end;
  end;
end;
type
  TTestClosure = object
    val: Integer;
    function less(element: Integer): Boolean;
  end;
function TTestClosure.less(element: Integer): Boolean;
begin
  Result:= element < val;
end;
procedure Test;
var
  stack: TTestClosure;
  data: TDataArray;
begin
  stack.val:= 10;
  data:= FilterData([2,4,8,10,12], stack.less);
  assert(Length(data) = 3);
end;                         

In our previous episode, Ryan Joseph said:

In our previous episode, Ryan Joseph said:

The problem is that the C++ object model is more complex and tiered because of it. Also the Pascal class mode has complications of its own (like the multi stage constructor system and its link to exceptions) that might be additionally complicating when stressed over two very distinct use cases.

Compare it with the situation with multiple inheritance. C++ supports more in theory, but interfaces are more convenient and cover most scenarios. Yes, full MI coverrs more uses cases, but are the added ones really used a lot?

We must remain critical, and not declare C++ as the gospel

And then we come back to real and preferably common usecases that are an improvement over the
current situation.

I've used quite a lot more of records-with-methods in the last two years due to a lot of OpenGL and charting related work, so I'm not as against extensions in this area than I used to, but I can't really imagine the practical uses yet, and I don't instantiate that many classes locally and kill them again. Most messenger types are already records, and I can't remember any moment that it was a problem that they were not in the inheritance hierarchy. (Maybe streaming?)

Mostly stuff like TStringLists for splitting strings, but those are not really the kind of high performance usage that benefits from being stack based.

Yes, I can vaguely see some minor syntactic sugar benefits of a autoinstantiation object. (preferably done in a delphi compatible way) Though IMHO improving the IDE wizards to create the skeletons more efficiently (declare-create-try -finally-release) is equally valid.

But I'm afraid this is all just language grafitti, where everybody wants to put its stamp on the language with a lot of little used extensions.

The challenges that Pascal faces are for the most not language related.

Look at the little code snippet I just posted using code from another post. It?s a good example of the kind of pattern I wanted to optimize. It?s save a little block of code and a call to GetMem which is good considering how little effort goes into the keyword. In functions called from tight loops it?s actually a big save.

You mean the faulty one that frees stream twice (once because it passes stream to en which frees it), and doesn't free stream if freeandnil(en) gives an exception because they are in the same finally block?

Well, actually if you said you used C++ for non system or high performance applications in 2018, I think you would get the same look.

I gave up Mac years ago, and from what I see in mails, installing still seems to be a big problem, mostly due to the binutils. Anyway, that is for somebody else to comment on. I simply don't know much about current Mac, since my last one was a G5, and I decided not to continue because Apple deprecated carbon.

That said, I'm really happy that Microsofts next gen (UWP) platforms and store haven't really taken off yet.

In our previous episode, Ryan Joseph said:

> I think if you want to pursue this, you must be much more concrete. Both the > benefits and the potential pitfalls. What are the potential pitfalls?

I was thinking more about complicating the constructor case, but then I saw the code you posted with two mistakes in 4 lines :-)

Objects are not a complete implementation and lack features of classes (no interfaces mainly and constructing requires the new keyword). The syntax I propose lets you allocate classes on the stack on a per-request basis which means you can use the class on the heap when you need to pass it around, or on the stack when you know the life cycle of the class during compile time.

Isn’t that a better option then using Objects and getting stuck with their syntax?

Regards,
Ryan Joseph

No, because it introduces additional complications.

We can think of extending the features of objects or advanced records. Your proposal entails a very different model of handling, which matches more how objects and records are currently handled.

Michael.

In our previous episode, Marco van de Voort said:

Ah, no the original code had two mistakes, the new code only one (the double free).

It does illustrate that the finalization of every object would have to be in its own try finally block though.

Yes you're right. Like the example I posted it’s highly common to make array wrappers like TList and then kill them at the end of the function but this isn’t something you’d do in tight loop anyways. I guess what gets me is knowing that what I’m doing is 100% for certain a waste (like calling GetMem) so it’s itches the programmer part of my brain that wants to be efficient at all costs. :)

Practically speaking the only time this will impact performance is with real time application and graphic processing or games. I’m looking my code now and it’s hard to find examples but there’s cases in the main loop (at 60fps) where I ‘m calling GetMem hundreds or thousands of times to allocate little helper classes that get used in functions. The best solution now is to reuse classes (which means storing them outside the function) and allocate once but it would be cleaner to not do that.

Sorry I don’t use the IDE or Delphi so I don’t know what goes on there.

But I'm afraid this is all just language grafitti, where everybody wants to put its stamp on the language with a lot of little used extensions.

I get that and maybe you’re right. It’s hard to say when a pattern is so common it deserves it’s own place in the language. I see this as a minor optimization like “inline” and beyond that just syntactic sugar.

The challenges that Pascal faces are for the most not language related.

It would be hard to get new programmers to adopt Pascal given how easy to use languages like Java, C#, Swift are these days. All the talking about manually memory management is a thing of the past for most programmers out there today. Pascal will get left behind but it can still survive as a low-level performant language like C++ so that’s where my motivations are for Pascal.

Then that was a bad example but the principle remains true. If you looked at the code you’d find that same pattern over and over again I’m sure.

True indeed. We’re clearly on the legacy end of languages so it would be wist to make the best of it.

Apple is doing everything they can to make it difficult for us. I’m not sure how all the Objective-C people are taking this but Apple is really pushing people towards Swift and they’ll deprecate everything eventually. Jonas did a brilliant job making Objective Pascal work but it’s just too great of an uphill battle.

That said, I'm really happy that Microsofts next gen (UWP) platforms and store haven't really taken off yet.

Regards,
Ryan Joseph

Isn’t putting a stack based pointer inside the class syntax easiest? Maybe I don’t understand but it seems to be you’re just swapping a pointer around.

After I had the idea this morning it’s appearing now that is more of optimization like “inline” or “constref" which basically says “this class exists only for this scope” so the compilers knows it can not call GetMem and call the destructor at the end of the scope. It’s not really a new model, just an optimization on classes which is meant to solve a very particular and frequent pattern of alloc on function start/dealloc on function end.

That sounds really good and simple to me but I believe me I understand why the compiler teams doesn’t like to add features and clutter up the language. It’s a hard call.

Regards,
Ryan Joseph

Sorry guys that was technically a bad example but it does illustrate the usage pattern and I think we can all identity it as being very common. It’s a smart optimization because we know with 100% certainty that those classes are only meant to be around for the duration of that functions body so we can optimize away the unneeded call to GetMem and calling Free when the function terminates. It’s like using “constref” for functions when you want to avoid a needles copy-on-pass, especially when the size is large. It’s just wasteful and could be avoided with a simple keyword.

Regards,
Ryan Joseph

It's more than that.

After I had the idea this morning it’s appearing now that is more of optimization like “inline” or “constref" which basically says “this class exists only for this scope” so the compilers knows it can not call GetMem and call the destructor at the end of the scope.

The compiler does not call constructor does. In fact; it calls a class method of the object which will allocate the necessary memory. There is, in general, no telling what this call will do.

Michael.

In our previous episode, Ryan Joseph said:

As long as you remember there is a choice. Problems that are purely amount of typing are often better solved in the IDE without having yet another shortcut syntax.

Fundamental changes in the object model are never minor. Delphi/Object Pascal does not allow static objects, so that is a big thing.

> The challenges that Pascal faces are for the most not language related. It would be hard to get new programmers to adopt Pascal given how easy to use languages like Java, C#, Swift are these days.

I doubt that. This is exactly what I mean with not being language related.

To attract them you will have to show attractive usecases, not minor syntax.

The size of the framework, platforms and vendor support is what is the main attraction.

All the talking about manually memory management is a thing of the past for most programmers out there today. Pascal will get left behind but it can still survive as a low-level performant language like C++ so that?s where my motivations are for Pascal.

Maybe, but then I think creating a new dialect that takes these features to the core is preferable, rather than some crutches to a dialect/compiler with a different bent. Because you risk having the worst of both worlds otherwise.

Then that was a bad example but the principle remains true. If you looked at the code you?d find that same pattern over and over again I?m sure.

Yes, but I think to see if syntactic sugar is worth it, you should be looking at business code, not component code, which is usually more iteratively and carefully crafted.

> Well, actually if you said you used C++ for non system or high performance > applications in 2018, I think you would get the same look. True indeed. We?re clearly on the legacy end of languages so it would be wist to make the best of it.

It smells too much of dressing up the pig to me.

On Apr 25, 2018, at 8:06 PM, Marco van de Voort wrote: Fundamental changes in the object model are never minor. Delphi/Object Pascal does not allow static objects, so that is a big thing.

I guess I’m not seeing this same way as others are. It seems like if we have a stack of static memory we should we able to use that instead of GetMem if we want to (like is possible for all other types). GetMem just find a memory address from RAM so why can’t there be a function that finds a memory address from the stack? In my mind I’m seeing this as a transparent implementation detail that the class handles for you inside the class method which allocates the classes internal pointer. Something in me says that we have this memory mapped at compile time so we should be able to access it.

well having said all that I understand why it’s easy to dismiss because it’s frankly one of dozens of new features you could add to FPC.

Certainly this is a crutch because there isn’t a full ARC system. I see it as an easy solution and a quick fix to get a little more utility out of the language without overhauling everything. Are there actual plans to make a new dialect of FPC? At this point I don’t know what the language would need to do to make it competitive with new entries into the market. Even if it was easy to use Pascal in Xcode and make iOS apps with native frameworks I don’t think new users would trade Swifts ease of use for a faster, albeit cumbersome old school language like Pascal.

Regards,
Ryan Joseph

'make it competitive with new entries in the market' is not a goal of the free pascal team.

This is a hobby project for most devs. Monetary gain is not a goal.

Probably sounds like an anachronism in this day and age, but there you are...

Michael.

That’s what I thought initially. I understand Pascal is a hobby for many here and they’re doing their best to keep the language alive in the face of an ever changing market. Personally I just want Pascal to be the best it can be so I can continue to use it in the future without making more and more compromises in productivity.

The team has done a good job keeping up with the best (or at least popular) new ideas in programming (like Generics, records with methods, interfaces) and that’s why I like to share what ever ideas I have in case they’re useful. Small things like “constref” are nice and go a long way to making the language feel good to use.

Regards,
Ryan Joseph

2018-04-25 15:38 GMT+02:00 Ryan Joseph :

Are there actual plans to make a new dialect of FPC?

Yes this is possible but for now it has not much sense. My personal roadmap :

1. clean up few things for Generics.Collections and some bug fixes for generics
2. merge for FastRTTI ( https://github.com/maciej- izak/freepascal/tree/fastrtti ) which is related to speed up managed types (also very important for management operators)
3. "default field" functionality for smart pointers / simple ARC classes
4. finish work for closures
5. few parts of extended RTTI
6. aspects

after point "3" new mode has more sense but after "6" is rather obligatory ;).

Ryan Joseph wrote

The team has done a good job keeping up with the best (or at least popular) new ideas in programming (like Generics, records with methods, interfaces) and that’s why I like to share what ever ideas I have in case they’re useful.

Do you know MSElang objects?
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects

Martin

On Apr 25, 2018, at 8:59 PM, Maciej Izak wrote: 4. finish work for closures

Having closures in FPC would be a major milestone.

5. few parts of extended RTTI 6. aspects

what’s aspects?

after point "3" new mode has more sense but after "6" is rather obligatory ;).

Don’t forget about default constructors for records. :) The syntax is already there for declarations. It would be so nice. ;)

var
  p: TPoint;
begin
  p := TPoint(x: 0, y: 0)

Regards,
Ryan Joseph

On Apr 25, 2018, at 9:00 PM, Martin Schreiber wrote: Do you know MSElang objects? https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects

I agree with you on this point, and it’s what I prefer FPC be like but adopting a new variant of Pascal and new compiler is just beyond what I could invest into. Extending FPC is probably the best time investment if at all possible.

Regards,
Ryan Joseph

I want the same for pascal.

But I really still need to see convincing evidence that language features contribute to productivity.

Available libraries for common programming tasks - and I mean this on a high-level level - are infinitely more important, so I don't need to get down to the gory details of many tasks:

* Creating a PDF.
* Creating a good-looking report from Data.
* Have an API that reads google protocol data.
* A good ORM/OPF.
* Reading a smartcard.
* Access a Google,Facebook,Twitter, MS or what-have-you-not REST API.
* A wizard that makes a Data entry form based on a TDataset or object.
* Classes to make a REST API.
* Classes to make/consume a SOAP service.
* Code that transforms a JSON structure to object classes plus the code to
* read/write the JSON.

These are things that make me win time.

a low-level feature such as Memory management is really the least of my worries. Use TComponent or reference counted interfaces if such things bothers you.

Michael.

I totally agree that available libraries like the above are what attract (or keep existing) users to Pascal, not some minor syntactical  sugar. E.g.
  people new to AI will learn python just because there are ready libraries in AI callable by python.
  People new to statistics will learn R just because there are ready libraries of statistics in R.
  People new to iOS will learn swift because it allows them easily call all the libraries of iOS, not because swift is better than Pascal or Java.

It is about convenience.

Dennis

On Apr 25, 2018, at 9:27 PM, Dennis wrote: People new to iOS will learn swift because it allows them easily call all the libraries of iOS, not because swift is better than Pascal or Java.

It’s worse than that because Apple has designed Swift to work with how their frameworks are designed. All part of the Apple walled garden that crushes competition. Swift is in fact a trap to further control the software on the platform.

Regards,
Ryan Joseph

At work I've recently used Free Pascal to interface our accounting system to our WordPress WooCommerce store using Free Pascal's built in JSON support, fphttpclient, etc.

I could list off a bunch of new languages with goofy names that could have done it, but Free Pascal did it just fine.

Just a few years ago I might have been writing a wrapper around someone else's command line utility or trying to interface with some DLL file written in C/C++

That stuff is definitely a huge deal. :) (and to whomever might be reading this that worked on those, thanks!)

That would be me :)

Michael.

what kind of applications are people using FPC for in 2018? Honestly I’m only going to be using FPC in the future for games or real time graphics. Maybe GUI’less apps like servers if I ever had a need. Not sure what else I could do with it.

Is it still competitive for Windows GUI apps? In terms of platforms it’s all but dead on Mac/iOS and Android is all Java right? Games are still a go though.

Regards,
Ryan Joseph

If all your writing is a one pass script then JSON and HTTP is so easy with PHP. Anytime I’m looking to write some crappy code that works just well enough for the task I go to PHP. I’m surprised they let you use Pascal at work even. :)

Regards,
Ryan Joseph

Well with an attitude like that, here's hoping you leave the pascal community sooner than later :)

... and Android is all Java right?

AFAICR it's now Kotlin, Java, C++ and FPC in order of support and ease of use.

R.

Ryan Joseph schrieb am Mi., 25. Apr. 2018,
15:38:

Certainly this is a crutch because there isn’t a full ARC system. I see it as an easy solution and a quick fix to get a little more utility out of the language without overhauling everything.

What you are suggesting is neither an easy nor a quick fix, because you're touching the fundament of the class system where both the compiler and the RTL make heavy assumptions about.
The way to go is an ARC system using Maciej's default fields.

Regards,
Sven

A strange point of view.

From my point of view, you can do anything with FPC.

Why would you not be able to build a GUI app with FPC/Lazarus ?

The only difficult thing at this point - from my point of view - is interaction with some Microsoft products such as an exchange server, Active directory etc. where all the 'easy access' methods are only available as .NET assemblies.

And even so, with these things more and more moving to the cloud, FPC becomes again an option if you need to access these services.

Michael.

In our previous episode, Michael Van Canneyt said:

My first active directory application with FPC was with FPC 1.1 in 2003 :-)

Just using winapi functions. IIRC it was to get some information tables for the exchange team. You might still need winapi-jedi, as I did though :_)

I know this exists, but things have changed considerably since 2003 :)

Michael.

Hi,

I totally agree that available libraries like the above are what attract (or keep existing) users to Pascal, not some minor syntactical  sugar.

But syntax features attract the library developers that will write those attractive libraries

Cheers,
Benito

Nonsense. You can find any library you want in C.

And C is even more primitive than pascal.

Michael.