Hello list,

I don't know if here is the correct place to make this question.

I read that mails about implementation of management operators and smart pointers.

1 - These features are expected to be available in which version?

2 - Are these features an introduction to Arc objects?

Best regards

pointers.

1 - These features are expected to be available in which version?

They are currently worked on in a branch. Once they are merged they would be in trunk which currently is 3.1.1. At the earliest the feature would be on 3.2.0.

2 - Are these features an introduction to Arc objects?

In the case of that implementation the instances themselves wouldn't be reference counted, but the containers they're passed around in would be (like C++ smart pointers).

Regards,
Sven

2016-05-09 19:50 GMT+02:00 Mazo Winst :

The feature is ready and works almost perfectly but I need more time to tests. It brings also nullable types (nullable type is kind of smart pointer) and it brings new kind of type helpers for example for dynamic arrays, interfaces and in practice for any other types (side effect of new syntax ;) ).

IMO there is very weak chance for merging into official FPC trunk. FPC core team has strong opposition to new features like in Oxygene or Delphi Nextgen/ARC. "Smart pointers idea" is main point of my further work, plans are much more deeper.

Because of that I've decide to fork (ofc I will try to track trunk as long as possible - hopefully always). All will be available together with Generics.Collections as part of RTL at:

-> https://github.com/dathox/freepascal (source) + maybe http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/maciej/ -> http://objectpascal.space and http://freesparta.com (binary + new site - in progress)

I think that summer is a realistic date to put all together. Above links are invalid for now.

2 - Are these features an introduction to Arc objects?

Yes, is possible to create {$MODE DELPHINEXTGEN} and these features are an introduction to ARC objects (with full backward compatibility and with great compatibility with Delphi Nextgen, also will be possible to link ARC modules with "non-ARC" modules and vice-versa).

Who said that? We discussed the syntax etc. and at least I see good changes to integrate it in trunk as soon as it is ready. Neither Sven nor me would discuss a feature if we are in doubt that it will make it in trunk.

FPC core team has strong opposition to new features like in Oxygene or Delphi Nextgen/ARC.

It is more a matter of doing it properly. It is more an opposition against quickly hacked together stuff without proper testing etc. I am pretty sure that we get ARC soon or later in trunk, if somebody shows enough dedication :)

After all, FPC tries to support as much as possible pascal dialects in OSS compiler. But this does not mean, we are supporting everybody's pet dialect ;)

I agree with Florian regarding the management operators. They will probably be merged.
What I'm not in favor of however is overloading of "." and such (but you haven't put that up for discussion yet, thus for now I'm not considering it part of your branch anyway).

Regards,
Sven

2016-05-09 22:11 GMT+02:00 Florian Klämpfl :

I have feeling that Sven has negative attitude to my work (like in thread "Initialize/Finalize management operators and Default intrinsic"). I have also bad experience with Generics.Collections (submitted 2014-12-23)... which should be part of RTL for a long time... For outsider like me, is almost impossible to contribute changes to trunk. I think it will take few years before someone checks branch. Sven is the only person in core team who is working on new things, additionally he has a lot of things in TODO list so IMO merge will never happen, the queue is long: packages branch, attributes branch, rtti for interfaces branch, anonymous methods branch...

Oxygene in FPC core team opinion is not Pascal language. So my work for Oxygene compatibility is "outlawed" by definition. "Smart pointer" related syntax is step into Oxygene mode so dedication might be not enough :P.

Seems like my own little FPC fork + small website to host binaries, according to current situation is rational step, especially I need to merge few other branches together... I can't wait whole life.

2016-05-09 23:23 GMT+02:00 Sven Barth :

I agree with Florian regarding the management operators. They will probably be merged.

probably = wait few years + rather no

;)

What I'm not in favor of however is overloading of "." and such (but you haven't put that up for discussion yet, thus for now I'm not considering it part of your branch anyway).

New modifier to achieve overloading of ".", "@", "@@", "^" is not committed yet. There is no discussion yet because my research is in progress. I have few working versions I need to decide which one is the best. The new syntax/compiler behavior is developed for many new elements (nullable types, smart pointers, arc objects) and must be perfect.

Maciej,

Hey I'm all for your improvements. Good work, keep it up, and I actually appreciate it. If you want, I can write up an overview of your improvements at getlazarus.org and provide precompiled versions for testings/use on all platforms (win, mac, linux, raspbian)..

I asked Sven the other day about type helpers on generic array types and there was no hint in his response that it was on anyone's radar. I think you mentioned you have type helpers working on arrays then that's great. Specifically I was asking about:

type
  TArray<T> = array of T;
  TArrayHelper<T> = record helper for TArray<T>
    // Extensions here like Add(), Remove(), Sort() and so on
  end;

Which probably isn't something you or anyone else has implemented yet because of the generic factor. Actually support for type helpers for any generic types (classes, records, interfaces, arrays) would be great, especially when combined with the work you've done on record initialization and finalization.

2016-05-10 11:26 GMT+02:00 Anthony Walter :

glad to hear that ^^. I think is good idea to wait for smart pointers. I will let you know in PM.

Which probably isn't something you or anyone else has implemented yet

With my private "not committed yet" version of compiler I can compile code like that (I think the good name for below construction is "specialized helper" or "forced helper" or just "record with default field"):

{ be aware that code below is experimental }
type
  TManagedArray<T> = record
    Instance: TArray<T> default;
    function Add(A: T): Integer;
  end;
function TManagedArray<T>.Add(A: T): Integer;
begin
  Result := Length(Instance);
  SetLength(Instance, Succ(Result));
  Instance[Result] := A;
end;
procedure foo(A: TArray<Integer>);
begin
  WriteLn(a[0]); // 10
end;
var
  a: TManagedArray<Integer>;
  pa: ^TArray<Integer>;
  i: Integer;
begin
  a.Add(10);
  i := a[0]; // compiler magic, equivalent of: i := a.Instance[0];
  foo(a); // compiler magic, equivalent of: foo(a.Instance);
  pa := @a; // compiler magic, equivalent of: pa := @a.Instance;
  WriteLn(pa^[0], ' = ', i); // 10 = 10
end.

probably: depends on you if it gets into agood shape :)

Aren't there several bug reports open which must be fixed first?

For outsider like me, is almost impossible to contribute changes to trunk. I think it will take few years before someone checks branch. Sven is the only person in core team who is working on new things,

Well, the others are all busy with cleaning up and fixing old stuff. And still, the bug count increases. This is also one of the reasons why probably nobody is really happy to merge another branch with new features.

Maciej,

From your example code, the usage looks exactly like what I'd want. One

question though. Would the magic code also work with var and out arguments?

That is with (note these functions are generic):

procedure Foo1<T>(A: TArray<T>);
procedure Foo2<T>(var A: TArray<T>);
procedure Foo3<T>(out A: TArray<T>);

Where each can be called with a TManagedArray<T> as the "A" argument without qualifying the Instance field?

var
  A: TManagedArray<Integer>;
begin
  Foo3(A);
  Foo2(A);
  Foo1(A);
end;

2016-05-10 21:18 GMT+02:00 Florian Klämpfl :

Aren't there several bug reports open which must be fixed first?

There is one critical bug related to class var and generics, but as Sven said it need wait to "packages branch"...

With other bugs we can +/- live. ;)

btw I've started to fix few of them...

2016-05-10 22:33 GMT+02:00 Anthony Walter :

From your example code, the usage looks exactly like what I'd want. One question though. Would the magic code also work with var and out arguments?

Yes.

Yes, anyway example is buggy because we don't have "type inference" for generic methods/functions like in Java (which is on my TODO list), but is possible to compile and run example like this:

var
  a: TManagedArray<Integer>;
begin
  Foo1<Integer>(a);
  Foo2<Integer>(a);
  Foo3<Integer>(a);

without qualifying the Instance field?

Yes, anyway example is buggy because we don't have "type inference" for

generic methods/functions like in Java (which is on my TODO list), but is possible to compile and run example like this:

Type inference is another topic you won't find many friends for...

Regards,
Sven

changes to integrate it in trunk

> as soon as it is ready. Neither Sven nor me would discuss a feature

if we are in doubt that it will

> make it in trunk. > > > I have feeling that Sven has negative attitude to my work (like in

thread "Initialize/Finalize

> management operators and Default intrinsic"). I have also bad

experience with Generics.Collections

> (submitted 2014-12-23)... which should be part of RTL for a long time... Aren't there several bug reports open which must be fixed first?

Those bugs mostly have workarounds. The main point was the usage of manual interfaces, but I'm mostly at peace with that by now (or more like a ceasefire ;) ). Scrolling through the code I saw one other thing. I'll have to check that again and after that the code cam probably be integrated with the main problem being the location, e.g. rtl-generics or fcl-generics or whatever...

Regards,
Sven

Am 11. Mai 2016 12:06:07 vorm. schrieb Sven Barth
:

the main problem being the location, e.g. rtl-generics or fcl-generics or whatever...

If it depends on classes: fcl-generic, else RTL-generic.

In our previous episode, Florian Kl?mpfl said:

> whatever... If it depends on classes: fcl-generic, else RTL-generic.

Some rtl-objpas units use classes, like fmtbcd.

If you don't use fcl-base I would make it RTL, so we can use it in fcl-base if needed :-)

2016-05-11 10:22 GMT+02:00 Marco van de Voort :

Some rtl-objpas units use classes, like fmtbcd. If you don't use fcl-base I would make it RTL, so we can use it in fcl-base if needed :-)

Library is low level without using anything outside RTL, IMO it should be part of RTL like in Delphi.

Note that I need the library as part of RTL not as package. Generics.* contains _LookupVtableInfo/_LookupVtableInfoEx and few other things which are used for my next compiler work...

Generics.* as package will complicate all my plans -,- . If it can't be part of RTL, more comfortable for me is excluding whole library from FPC (easier maintenance of FreePascal fork...)

Anything the compiler needs *must* be in the system unit. The compiler should only assume the system unit, possibly objpas or macpas or so.

All the rest should remain out of the RTL, which should be as small as possible. So rtl-generics is your best bet. Even the classes unit is better outside the rtl, but I think Marco is reluctant to remove it.

I have remarked on this before: this tight dependency you are creating is very worrying.

Michael.

2016-05-11 13:46 GMT+02:00 Michael Van Canneyt :

FPC team is very selective and with double standards and that is very worrying. For example fgl module is part of RTL just because is usefully for Sven for testing purposes (! that is curious). There is no reason in keeping that module in RTL but is in RTL because we have double, selective and irrational standards. Generics.* is absolute other category of module with base and complex support for *any* stuff related to generics + has better testing purposes than fgl.

Please just don't add Generics.* into FPC as package. :/

In our previous episode, Maciej Izak said:

Delphi's decisions are irrelevant. (and they regroup across directories every other version too)

There is no reason to compile these reasonably large units 3 times. The only reason to keep them in the base RTL is because units there would need it (like a unicode classes version)

Note that I need the library as part of RTL not as package. Generics.* contains _LookupVtableInfo/_LookupVtableInfoEx and few other things which are used for my next compiler work...

Then consider spinning that out to a lower level unit. It is not a reason to stuff everything and the kitchen sink in the RTL.

Generics.* as package will complicate all my plans -,- . If it can't be part of RTL, more comfortable for me is excluding whole library from FPC (easier maintenance of FreePascal fork...)

In forks you are free to modify and move whatever you want. Usually in cases like this the developer doesn't want to use the more conservative version packaged with FPC, but one with a quick feedback with own changes.

And isolated in a package they are more easily disabled (edit one fpmake) then in the RTL (edit all targets makefiles)

There are no double standards ?

For example fgl module is part of RTL just because is usefully for Sven for testing purposes (! that is curious).

Where is that written ? As far as I know, it is only there because classes is there, and classes has some define to allow it to be compiled with fgl.

There is no reason in keeping that module in RTL

As said, I think classes may be moved as well, and then fgl may be moved as well.

but is in RTL because we have double, selective and irrational standards.

No, this is not so. See above.

The rtl needs to contain whatever is necessary to compile the compiler.

No more, no less.

Nevertheless, that is what is going to happen.

There should not be double standards.
If the consequence is that the fgl unit should move as well: No problem with that.

Michael.

In our previous episode, Michael Van Canneyt said:

(I don't know if that is the reason, but probably there was not much discussion about it because it is small)

> There is no reason in keeping that module in RTL As said, I think classes may be moved as well, and then fgl may be moved as well.

Indeed, this is only a working division, and nothing is set in stone, but the objective is to avoid letting the rtl get too big.

Originally that was because of speed reasons (packages/ can be built in parallel and rtl is compiled many times), but in retrospect packages/ is much easier to administer, and it makes life a bit easier for new porters.

With the current situation: imho yes. And even if there are changes they will be more directed to move more units out of the RTL rather than move than back.

2016-05-11 14:23 GMT+02:00 Michael Van Canneyt :

Where is that written ? As far as I know, it is only there because classes is there, and classes has some define to allow it to be compiled with fgl.

by Sven (29 January 2016 10:54 thread "Generics.Collections as package for Lazarus or package for FPC RTL"):

"also fgl is a nice test durog cycling the compiler that nothing basic was broken with generics; one of the main reason it's still in rtl and not rtl-objpas or rtl-extra"

keeping module in RTL just to have nice test to check compiler cycle is ... very very very strange.

There should not be double standards. If the consequence is that the fgl unit should move as well: No problem with that.

If we will keep right order then I have no problem with Generics.* as rtl-generics package, and I can realize my plans with compiler in other, more correct way.

Well I missed that, but I think this argument will be overruled, it is rather a weak one.

keeping module in RTL just to have nice test to check compiler cycle is ... very very very strange.

I agree. And hence I think we will move it.

See the reply by Marco. We'll be moving units out of RTL, rather than in. That includes fgl and classes (better late than never ;) ).

Michael.

"Maciej Izak" wrote

2016-05-11 14:23 GMT+02:00 Michael Van Canneyt : > > Where is that written ? As far as I know, it is only there because

classes

> is there, and classes has some define to allow it to be compiled with

fgl.

> by Sven (29 January 2016 10:54 thread "Generics.Collections as package

for Lazarus or package for FPC RTL"):

"also fgl is a nice test durog cycling the compiler that nothing basic

was broken with generics; one of the main reason it's still in rtl and not rtl-objpas or rtl-extra"

keeping module in RTL just to have nice test to check compiler cycle is

... very very very strange.

And I stand by that decision. Generics are a rather frickle feature and I want to know of critical failures as early as possible (and yes, I've made use of that already numerous times!), thus I prefer fgl to be part of the cycling and unlike fcl-stl or these Delphi compatible ones the fgl unit is comparatively small.

Regards,
Sven

2016-05-11 14:51 GMT+02:00 Sven Barth :

And that is double standard. I prefer Generics.* to be part of the compiler cycle. It perform better test for critical failures in my compiler code and for more advanced generics code. It is not only for Delphi compatibility it performs infrastructure to *any* generics library like Spring4D etc.

Sorry Sven but keeping fgl in RTL is ridiculous (!). There is no technical reason for that. Only your personal convenience. You can use normal tests suite like others.

Or maybe Marco reply is untrue?

Sven, you must run the testsuite for this.
So do Jonas and Florian. That is what it is for.

I have no doubt that generics are frickle. So are many other features. So this is in its core a lazyness argument, which I think is not very correct.

Michael.

2016-05-11 15:07 GMT+02:00 Maciej Izak :

To be clear: part with Generics.* is just irony. Like below proposition:

Can I add module SmartPointers.pp and few other modules as test to the RTL? I have few features (rather frickle features) and I want to know of critical failures as early as possible.

Looks like we have new *best practice* for new language features and new condition to add the module to RTL :)

...

Sven, seriously? I'm a confused and disgusted.

Actually, once classes should again use fgl for the TList etc. implementations. This was already done, but reverted again. I do not remember the reason though.

According to the log Michael had reverted it to break the dependency of Classes on fgl. Then Micha had again added the code under the FPC_TESTGENERICS define... Nothing more was given :/ Maybe I'll try and see whether the code in that define still works or what changes would be needed to get it working and up to state with the non-generic one again. :) (at least with 3.0.0 generics would definitely be up to the task now :D )

Regards,
Sven

10% Speed penalty. Generics code is slower.

Michael.

It is not a matter of being up to the task. I'm sure it is possible.

At the time, I did speed tests, and the generics-based code was 10% slower.

That was the clincher, together with "don't fix it if it ain't broken"

Michael.

Good :) If existing features are reasonable bug free and completed, we can discuss new featueres.