> 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 th
> 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. The
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 = c
> 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;
>
> S
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 becau
> 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 u
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 comp
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 need
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 t
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?
Actuall
> 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 o
> 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
a
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 sam
Thank you for continuously enhancing Free Pascal. Happy to see every new
feature :)
Is there any work ongoing about overloaded properties? E.g.
property x: integer read GetX;
property x[aindex: integer]: integer write SetX;
I know that declaring the property only once and overloading the getter
> 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 ways
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 percentages
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 t
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 special
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 tr
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 err
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 a
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 c
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 parame
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 existi
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 implici
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) y
> 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?
Is
> 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 = ^speciali
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
functi
> 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 TValues
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 FOOBAR
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 even
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 sh
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. Th
45 matches
Mail list logo
