Hi everyone,

This might not be the best place to ask, but my programming buddy keeps bugging me about it, since he wants access to generic functions and the volatile intrinsic.  When will the next version of FPC be officially released?

Gareth aka. Kit

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

No date has been set.

The branch has been made, I am slowly bringing the documentation up-to-date, when that is done (lots of things changed), we can start making builds.

I would not count on it before september, and even that is "iffy".

Michael.

Op 2019-05-30 om 09:05 schreef Michael Van Canneyt:

The branch has been made, I am slowly bringing the documentation up-to-date,

Speaking of which, I enabled unit bufdatatset in the FCL docs yesterday. I thought the stale references were a bug in fpdoc/chm, turned out the unit was simply not parsed ;)

An oversight on my end it seems, thank you very much !

Michael.

Op 2019-05-30 om 11:43 schreef Michael Van Canneyt:

I mention it because it might be worthwhile to check if all XMLs are enabled in the makefile. (conversion to fpdoc project to make it easier? An unit has to be added in 3 places in the makefile)

Anyway, another thing that might require some attention is "strict protected" and -private \keywordlinks in the REF manual. IOW making sure that keywordlinks with spaces work in all file formats.

It's on my to do for today to do that for -chm.

Not any more. The project file is used ?

home:~/docs> make pdf -n
../compiler/utils/msg2inc -TE ../compiler/msg/errore.msg messages.inc rm -f user.aux user.idx user.ilg user.ind user.log user.out user.toc user.tmp user.xref user.4ht cp -f preamble.report preamble.inc
pdflatex user
makeindex user.idx
pdflatex user
makeindex user.idx
pdflatex user
../utils/fpdoc/bin/x86_64-linux/fpdoc --macro=FPCDIR=.. --output=rtl.inc --project=rtl-project.xml --format=latex rm -f rtl.aux rtl.idx rtl.ilg rtl.ind rtl.log rtl.out rtl.toc rtl.tmp rtl.xref rtl.4ht cp -f preamble.report preamble.inc
pdflatex rtl
makeindex rtl.idx
pdflatex rtl
makeindex rtl.idx
pdflatex rtl
rm -f ref.aux ref.idx ref.ilg ref.ind ref.log ref.out ref.toc ref.tmp ref.xref ref.4ht cp -f preamble.report preamble.inc
pdflatex ref
makeindex ref.idx
pdflatex ref
makeindex ref.idx
pdflatex ref
../utils/fpdoc/bin/x86_64-linux/fpdoc --macro=FPCDIR=.. --output=fcl.inc --project=fcl-project.xml --format=latex rm -f fcl.aux fcl.idx fcl.ilg fcl.ind fcl.log fcl.out fcl.toc fcl.tmp fcl.xref fcl.4ht cp -f preamble.report preamble.inc
pdflatex fcl
makeindex fcl.idx
pdflatex fcl
makeindex fcl.idx
pdflatex fcl

Similar for html ?

Anyway, another thing that might require some attention is "strict protected" and -private \keywordlinks in the REF manual. IOW making sure that keywordlinks with spaces work in all file formats.

Here we are at the mercy of the latex converter...

Michael.

On May 30, 2019, at 4:18 PM, Ryan Joseph wrote: I didn’t realize generic functions were in the trunk. I’m not sure I got this implemented properly so it requires some code review but can we try to include “implicitfunctionspecialization” mode switch in the next release along the with actual feature? https://bugs.freepascal.org/view.php?id=35261

{ got blocked again, attempting to resend }

I didn’t realize generic functions were in the trunk. I’m not sure I got this implemented properly so it requires some code review but can we try to include “implicitfunctionspecialization” mode switch in the next release along the with actual feature? https://bugs.freepascal.org/view.php?id=35261

Specifically, for some time now I wanted to make a “ClearMem" function that doesn’t require passing the type but the insanely verbose syntax of generic functions makes it even longer. Honestly the syntax is so intrusive in ObjFPC mode that I would avoid using it all together.

What we have now:

var
 pt: TPoint;
begin
	FillChar(pt, sizeof(TPoint), 0);

Specialization with generics:

	specialize ClearMem<TPoint>(pt);

With implicit specialization:

ClearMem(pt); // :)

Regards,
Ryan Joseph

Op 2019-05-31 om 18:36 schreef Alexander Grotewohl:

You don't get size that way, and you have to pass it separately (see e.g. blockread/write).

It was one of the setbacks when I came back to TP/FPC from Modula2, the latter which does have an open array type with size attached to it.

Now I can see how that can be very useful, and certainly a lot cleaner and less error-prone.  I do wonder what it will do in regards to suppressing that annoying "uninitialized variable" warning though when passing said variable into FillChar to, you know, actually initialise it!

Admittedly, the feature I'm looking forward to are assembly language intrinsics, so I can finally optimise SwapBuffers on Intel systems to directly call BSWAP without having to use some compiler-specific nodes, although I sense that one will have to wait until the version after.

Gareth aka. Kit

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

I don't think this syntax is a good idea.

What with overloads ?

Procedure MyProc<T>(a:T);
Procedure MyProc(a : TObject);

How do I know which one will be called ?

Honestly, the idea of doing so many things "behind my back" is really not comforting.

Brevity goes always at the cost of understandability. Have a can express things really compactly.
But if you look at someone else's compact code (or your own code after 2 months) you no longer understand what exactly is happening.

Pascal is meant to be readable and understandable. Things like this diminish these qualities hugely.

Michael.

Once again: FPC needs a defined method resolution order, *and stick with it*.

The current ad-hoc inheritance/typeconv/:= overload/overload/operator overload
mess is already completely unpredictable and super buggy.

Based on a specificity approach, the answer to your question would be obvious: The latter if a is (a descendant of) TObject, a new specialization otherwise.

Really ?
I wonder what kind of code you write to make this 'super buggy' statement.

I myself write lots of code, and never encountered an issue. But then, I normally don't use dubious constructs to begin with.

In general of course I agree 100% with your statement that we need a clear resolution order.

Michael.

In fact, we already have several bug reports related to overloading/generics.

See
https://bugs.freepascal.org/view.php?id=27690
https://bugs.freepascal.org/view.php?id=30776
https://bugs.freepascal.org/view.php?id=28824

Michael Van Canneyt schrieb am Sa., 1. Juni 2019, 12:00:

It's required for Delphi compatibility.

The compiler calls the more specific one. I'd need to cross check with Delphi, but here I'd assume that it would be the TObject one as no specialization is required then.

Regards,
Sven

Indeed. It gets worse by the day :(

Michael.

No doubt. But I normally don't use generics.

Michael.

Some more non-generic-related ones, just ones I can remember right now: https://bugs.freepascal.org/view.php?id=35580
https://bugs.freepascal.org/view.php?id=31215 (don't mind the symptom, the cause is a typeconv issue)
https://bugs.freepascal.org/view.php?id=35573

What bugs me most is how one small fix (such as r42042) breaks other things that should be orthogonal but are not.

All because there are at least four partially recursive resolution methods following slightly different rules, all for the same question "given the passed argument defs, what is the path of least conversion to something of matching name in the current symtable?".
But yeah, that's just core having a different opinion of code duplication than I do.

Michael Van Canneyt schrieb am Sa., 1. Juni 2019, 14:13:

I personally consider it a worthwhile addition.

Regards,
Sven

Sure, each his opinion. It all depends on what one values in a language.

Michael.

Currently the non-generic gets called in this situation. That’s because non-generic procedures take precedence and TMyClass can be passed to TObject. That’s pretty simple right?

{$mode objfpc}
{$modeswitch implicitfunctionspecialization}
program timpfuncspez14;
type
  TMyClass = class
  end;
procedure DoThis(msg: TObject);
begin
  writeln('DoThis:',msg.ClassName);
end;
generic procedure DoThis<T>(msg: T);
begin
  writeln('DoThis<T>:',msg.ClassName);
end;
begin
  DoThis(TMyClass.Create);
  DoThis(TObject.Create);
end.

Regards,
Ryan Joseph

I think it would have to work like: if something is a TObject descendant (meaning, any class) and both of those functions were actually in scope, it would always pick the non-generic TObject one for them. Anything that could not validly be cast to TObject would have the generic one picked for it.

I can't really think of a good reason that someone would have both versions of the function side-by-side like that in reality, though.

On Sat, Jun 1, 2019 at 10:58 AM Sven Barth via fpc-devel <

wrote: I personally consider it a worthwhile addition.

What version did Delphi add that in? I honestly had no idea it was a thing.

Makes it seem especially strange that they still don't have freestanding generic methods.

I would personally consider this a
compiler error because there's too much
ambiguity and assumption involved when
choosing one over the other. In my eyes,
the correct choice is too unclear.

Gareth aka. Kit

On Sat 01/06/19 21:41 , Ben Grasset
sent:

On Sat, Jun 1, 2019 at 6:00 AM Michael

Van Canneyt wrote: I don't think

something is a TObject descendant

(meaning, any class) and both of those

functions were actually in scope, it

would always pick the non-generic

TObject one for them. Anything that could

not validly be cast to TObject would

have the generic one picked for it.

I can't really think of a good reason

that someone would have both versions

of the function side-by-side like that

in reality, though.

Ben Grasset schrieb am Sa., 1. Juni 2019, 22:49:

I don't know. I had first encountered it with TValue code which has a generic method where in examples the type parameter is sometimes left out.

Makes it seem especially strange that they still don't have freestanding generic methods.

Indeed. That's why I implemented them for FPC when I implemented generic methods.

Regards,
Sven

In fact, your choice of words betrays the reason:
They want everything to be objects or records, with methods.

The traditional term for 'freestanding methods' is simply 'procedure' or 'function'. Using them is 'procedural programming'.

So, they "deprecate" 'procedural programming'. All should become OOP. I really think it is a marketing decision, not a technical one.

Michael.

I just tried to declare these 2 procedures in 3.3.1 and got an error. You can declare them in the reverse order with no problem. A bug?

generic procedure DoThis<T>(msg: T);
begin
end;
procedure DoThis(msg: TObject);	// Overloaded identifier "DoThis" isn't a function
begin
end;

Regards,
Ryan Joseph

Yes, please report.

Regards,
Sven

https://bugs.freepascal.org/view.php?id=35670

Regards,
Ryan Joseph

2019. 05. 30. 9:05 keltezéssel, Michael Van Canneyt írta:

I would not count on it before september, and even that is "iffy".

Any news/update in this subject?

The fixes_3_2 branch created more than a year ago and the latest stable (3.0.4) released 2 years ago.

Gabor

Op 2019-11-30 om 09:29 schreef Gabor Boros:

Not much movement. My hope for a christmas holiday release is mostly gone.

My programming buddy has been asking me this question as well, and I can only say "I don't know".  Do we have a release candidate though?

J. Gareth Moreton wrote

My programming buddy has been asking me this question as well, and I can only say "I don't know".  Do we have a release candidate though?

No. https://bugs.freepascal.org/roadmap_page.php has still open entries.