[fpc-pascal] Stack alias for ARC like memory management?

[Marco van de Voort]

In our previous episode, Ryan Joseph said:
> > 
> > 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.
> 
> Sorry I don?t use the IDE or Delphi so I don?t know what goes on there.

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.

> > 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.

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.