> On May 1, 2022, at 10:36 AM, Hairy Pixels wrote:
>
> Not sure what the best solution is but here are the ones I can think of:
>
> 1) allow the helpers to use “array/set of T” syntax.
Sorry for the noise, one last point on this. So it looks like type helpers are
already so strictly typed
> On Apr 30, 2022, at 6:17 PM, Hairy Pixels wrote:
>
> 2) Right now helpers only support single types but they would need to be
> extended to support “array of T”, “set of T”,which by, why aren’t those
> supported as it is? I can’t seem to think of any reason they should be
> disallowed.
Hi,
Em sáb., 30 de abr. de 2022 às 09:13, Mattias Gaertner via fpc-pascal
escreveu:
>
> AFAIK it is planned for mode objfpc to support distinguishing types via
> template count as in mode delphi:
>
> type
> TMyClass = class
> end;
> generic TMyClass = class
> end;
> generic TMyClass =
> On Apr 30, 2022, at 7:02 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> AFAIK it is planned for mode objfpc to support distinguishing types via
> template count as in mode delphi:
>
> type
> TMyClass = class
> end;
> generic TMyClass = class
> end;
> generic TMyClass = class
> end;
>
>
On Sat, 30 Apr 2022 18:17:25 +0700
Hairy Pixels via fpc-pascal wrote:
>[...]
> So I wonder if the shorthand:
>
> generic THelper = class helper for TMyClass
AFAIK it is planned for mode objfpc to support distinguishing types via
template count as in mode delphi:
type
TMyClass = class
> On Apr 25, 2022, at 8:27 PM, Hairy Pixels wrote:
>
>> For some reason I don't get all mails by Ryan, so I reply here:
>>
>> Helpers currently can't be generic and even if they could be (which I do
>> plan to add) it would require an explicit specialization of the helper to be
>> used
> On Apr 25, 2022, at 7:14 PM, Sven Barth via fpc-pascal
> wrote:
>
> For some reason I don't get all mails by Ryan, so I reply here:
>
> Helpers currently can't be generic and even if they could be (which I do plan
> to add) it would require an explicit specialization of the helper to be
Mattias Gaertner via fpc-pascal schrieb
am Mo., 25. Apr. 2022, 13:50:
>
> >[...]
> > type
> > generic TArrayHelper = type helper for array of T
> > procedure Add(value: T);
> > end;
> >
> > var
> > a: array of integer;
> > begin
> > a.Add(1); // specialize TArrayHelper since the
On Mon, 25 Apr 2022 10:15:26 +0700
Hairy Pixels via fpc-pascal wrote:
>[...]
> For the case of types I understand we must specialize because we’re
> creating a new type each time and there is nothing to infer from the
> context, but for functions it’s backwards, that is we know the types
> being
On 25-4-2022 11:11, Sven Barth via fpc-pascal wrote:
Then you don't think creative enough. Think about (de)serialization
code for binary data which needs to use the correct size. If done
correctly this can very well be handled with a generic.
Actually that's what I immediate thought of too,
> On Apr 25, 2022, at 4:11 PM, Sven Barth wrote:
>
> Then you don't think creative enough. Think about (de)serialization code for
> binary data which needs to use the correct size. If done correctly this can
> very well be handled with a generic.
>
Oh yes that’s right. I guess I would
Hairy Pixels via fpc-pascal schrieb am
Mo., 25. Apr. 2022, 10:58:
>
>
> > On Apr 25, 2022, at 2:39 PM, Martin Frb via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Actually, it's dealing with SmallInt (or ShortInt). And if the
> programmer does not know that, then it might be an
> On Apr 25, 2022, at 2:39 PM, Martin Frb via fpc-pascal
> wrote:
>
> Actually, it's dealing with SmallInt (or ShortInt). And if the programmer
> does not know that, then it might be an issue...
>
> Imagine the generic code (something more complex than "Add") would somehow do
> something
On 25/04/22 05:15, Hairy Pixels via fpc-pascal wrote:
generic function Add(left, right: T): T;
And the programmer intends to call it like:
Add(1,1);
Why should the programmer need to tell the compiler it’s dealing with Integer
when it’s so obvious from the types being used?
> On Apr 23, 2022, at 9:09 PM, Hairy Pixels wrote:
>
> The two languages I use commonly these days are Swift and C#, both of which
> do implicit function specialization by default. After you use a generic
> function a couple times it becomes apparent the compiler could infer the
> types and
Op 24/04/2022 om 04:37 schreef Hairy Pixels via fpc-pascal:
On Apr 23, 2022, at 10:30 PM, Marco van de Voort via fpc-pascal
wrote:
Btw since you are afaik an Apple user, did you actually use conformant arrays,
or do you base this on UCSD/Borland dialects only?
I started with THINK Pascal
> On Apr 23, 2022, at 10:30 PM, Marco van de Voort via fpc-pascal
> wrote:
>
> Btw since you are afaik an Apple user, did you actually use conformant
> arrays, or do you base this on UCSD/Borland dialects only?
I started with THINK Pascal on classic Mac OS but I never heard of conformant
On 23-4-2022 16:09, Hairy Pixels via fpc-pascal wrote:
For 2) I'm also of the opinion of the others: this is unneeded syntactic sugar.
There is already a way to declare arrays with a specific size and for a
language it's in nearly all cases not good to provide multiple ways to achieve
the
: Sven Barth via fpc-pascal
To: fpc-annou...@lists.freepascal.org
Sent: Wednesday, April 20, 2022, 19:15:15
Subject: [fpc-pascal] Feature announcement: implicit generic function
specializations
Dear FPC community,
The FPC developers are pleased to announce the implementation of a new
feature
> On Apr 23, 2022, at 3:40 PM, Sven Barth via fpc-pascal
> wrote:
>
> For 2) I'm also of the opinion of the others: this is unneeded syntactic
> sugar. There is already a way to declare arrays with a specific size and for
> a language it's in nearly all cases not good to provide multiple
Am 22.04.2022 um 23:08 schrieb Rainer Stratmann via fpc-pascal:
Am Freitag, 22. April 2022, 19:53:34 CEST schrieben Sie:
Am 22.04.2022 um 15:48 schrieb Rainer Stratmann via fpc-pascal:
Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-
pascal:
We don't deal in
Am 23.04.2022 um 00:42 schrieb Martin Frb via fpc-pascal:
Possible one more / Though more of an optimization.
If the code has multiple
Add(Int64(0), Int64(0));
then they will all use the same procedure (just break in the debugger
and check the CRC).
But if one specialization is explicit
> On Apr 23, 2022, at 5:18 AM, Martin Frb via fpc-pascal
> wrote:
>
> Done
> https://gitlab.com/freepascal.org/fpc/source/-/issues/39684
> https://gitlab.com/freepascal.org/fpc/source/-/issues/39685
It looks like I need to do some cleanup phase. I can’t remember how it works
right now but I
Possible one more / Though more of an optimization.
If the code has multiple
Add(Int64(0), Int64(0));
then they will all use the same procedure (just break in the debugger
and check the CRC).
But if one specialization is explicit and the other implicit then 2
identical (as far as I can
On 22/04/2022 23:12, Sven Barth via fpc-pascal wrote:
Am 22.04.2022 um 20:51 schrieb Martin Frb via fpc-pascal:
So why does it generate "Add$1" if it does not use it? (Or rather why
does it warn, if this is some internal details?)
Add$1 is the symbol of the generic itself, *not* the
Am 22.04.2022 um 22:22 schrieb Mattias Gaertner via fpc-pascal:
On Fri, 22 Apr 2022 20:51:56 +0200
Martin Frb via fpc-pascal wrote:
[...]
Well, I tested: It uses the type of the first Param. So it calls a
function for both param of type Byte. The cardinal argument is
converted. (potentially
Am 22.04.2022 um 20:51 schrieb Martin Frb via fpc-pascal:
I created a little test program (see bottom of mail).
And it gives a strange warning:
Compile Project, Target:
C:\Users\martin\AppData\Local\Temp\project1.exe: Success, Warnings: 1,
Hints: 3
project1.lpr(67,52) Warning: Range check
Am Freitag, 22. April 2022, 19:53:34 CEST schrieben Sie:
> Am 22.04.2022 um 15:48 schrieb Rainer Stratmann via fpc-pascal:
> > Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-
pascal:
> We don't deal in percentages, however it reduces the amount of typing
> required to write
On Fri, 22 Apr 2022 20:51:56 +0200
Martin Frb via fpc-pascal wrote:
>[...]
> Well, I tested: It uses the type of the first Param. So it calls a
> function for both param of type Byte. The cardinal argument is
> converted. (potentially truncated).
I agree that Delphi should have used a better
On Fri, 22 Apr 2022 20:51:56 +0200
Martin Frb via fpc-pascal wrote:
>[...]
> I did explore what happens if I throw different types at it, and see
> how the current implementation deals with this (what I call) lack of
> type safety.
> And also asked the question, how should it act? (Because the
On 20/04/2022 19:15, Sven Barth via fpc-pascal wrote:
This feature allows you to use generic routines (functions,
procedures, methods) without explicitely specializing them (“<…>” in
Delphi modes and “specialize …<…>” in non-Delphi modes) as long as the
compiler can determine the correct
Am 22.04.2022 um 15:48 schrieb Rainer Stratmann via fpc-pascal:
Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-pascal:
This feature is enabled with the modeswitch
ImplicitFunctionSpecialization and is for now not enabled by default as
this has the potential to break
On 22/04/2022 17:13, Rainer Stratmann via fpc-pascal wrote:
Am Freitag, 22. April 2022, 17:27:33 CEST schrieb Hairy Pixels via fpc-pascal:
On Apr 22, 2022, at 8:48 PM, Rainer Stratmann via fpc-pascal
From assembly to high-level language there is a huge step.
From high-level language to
Am Freitag, 22. April 2022, 17:27:33 CEST schrieb Hairy Pixels via fpc-pascal:
> > On Apr 22, 2022, at 8:48 PM, Rainer Stratmann via fpc-pascal
> It’s like everything else in programming languages.
>
> 1) you can specialize the function manually so implicit specialization is
> not needed.
> 2)
> On Apr 22, 2022, at 8:48 PM, Rainer Stratmann via fpc-pascal
> wrote:
>
> How many percent of the users need this feature?
> Is it a feature that is a must?
> Can everyone get also a solution without the feature?
> Does it justify the risk of the whole language (has the potential to break
Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-pascal:
> This feature is enabled with the modeswitch
> ImplicitFunctionSpecialization and is for now not enabled by default as
> this has the potential to break existing code.
How many percent of the users need this feature?
> If you want to pass a pointer to ^T in a generic function is there anyway
> safe to do this currently? Pascal doesn’t allow ^ types in function arguments
> (why?) and generics don’t seems to support pointers either (why?).
>
> generic TValues = array[0..0] of T;
> generic PValues =
On Fri, 22 Apr 2022, Hairy Pixels via fpc-pascal wrote:
If you want to pass a pointer to ^T in a generic function is there anyway safe to do this currently?
Pascal doesn’t allow ^ types in function arguments (why?)
Because it is a type definition and you can't put type definition in a
> On Apr 20, 2022, at 1:15 PM, Sven Barth via fpc-pascal
> wrote:
>
> Writeln(Apply(@StrFunc, 'Foobar')); // will write FOOBAR
> Writeln(Apply(@NegFunc, 42)); // will write -42
For Sven, this reminds me, since we got this merged in now does that mean
closures are ready? :D
Regards,
If you want to pass a pointer to ^T in a generic function is there anyway safe
to do this currently? Pascal doesn’t allow ^ types in function arguments (why?)
and generics don’t seems to support pointers either (why?).
generic TValues = array[0..0] of T;
generic PValues = ^specialize
On Thu, 21 Apr 2022 10:00:46 +0200 (CEST)
Michael Van Canneyt via fpc-pascal
wrote:
> On Thu, 21 Apr 2022, Hairy Pixels via fpc-pascal wrote:
>
> >
> >
> >> On Apr 21, 2022, at 3:48 AM, Mattias Gaertner via fpc-pascal
> >> wrote:
> >>> Writeln(Apply(@StrFunc, 'Foobar')); // will write
On Thu, 21 Apr 2022, Hairy Pixels via fpc-pascal wrote:
On Apr 21, 2022, at 3:48 AM, Mattias Gaertner via fpc-pascal
wrote:
Writeln(Apply(@StrFunc, 'Foobar')); // will write FOOBAR
Writeln(Apply(@NegFunc, 42)); // will write -42
end.
Mind boggling. :)
This was actually your idea if
> On Apr 21, 2022, at 3:48 AM, Mattias Gaertner via fpc-pascal
> wrote:
>
>> Writeln(Apply(@StrFunc, 'Foobar')); // will write FOOBAR
>> Writeln(Apply(@NegFunc, 42)); // will write -42
>> end.
>
> Mind boggling. :)
This was actually your idea if I remember correctly. :) I think you said
On Wed, 20 Apr 2022 19:15:15 +0200
Sven Barth via fpc-pascal wrote:
>[...]
> This feature is enabled with the modeswitch
> ImplicitFunctionSpecialization and is for now not enabled by default
> as this has the potential to break existing code.
Sad. This feature really makes generic functions
That seriously improves generic code readability. Definitely worth trying to upgrade. Thanks a lot! 20:15, 20 апреля 2022 г., "Sven Barth via fpc-pascal" :Dear FPC community,The FPC developers are pleased to announce the implementation of a new feature: implicit generic function specializations.
Dear FPC community,
The FPC developers are pleased to announce the implementation of a new
feature: implicit generic function specializations. This feature was
implemented by Ryan Joseph, so thank you very much, Ryan.
This feature allows you to use generic routines (functions, procedures,
46 matches
Mail list logo
