I hope you're all having a lovely Coronavirus lockdown-vacation and keeping
safe. :)
I finally got around to the overhaul of {$modeswitch
implicitfunctionspecialization} as according to feedback in this thread. I
attached a patch in the bug tracker which should apply without conflicts. In
Am 10.10.2019 um 22:41 schrieb Ryan Joseph:
On Oct 9, 2019, at 6:21 PM, Sven Barth via fpc-pascal
wrote:
Hmmm, I thought letting that dummy sym pass through would have lots of adverse
affects in various places. I’ll have to study this later in the debugger.
In that case the necessary
> On Oct 9, 2019, at 6:21 PM, Sven Barth via fpc-pascal
> wrote:
>
> Hmmm, I thought letting that dummy sym pass through would have lots of
> adverse affects in various places. I’ll have to study this later in the
> debugger.
>
> In that case the necessary parts would need to be made more
Ryan Joseph schrieb am Mi., 9. Okt. 2019, 22:53:
>
>
> > On Oct 9, 2019, at 1:51 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Yes, exactly that. It could also be that the parser picks up a non
> generic overload from another unit (due to the order of units in
> On Oct 9, 2019, at 1:51 AM, Sven Barth via fpc-pascal
> wrote:
>
> Yes, exactly that. It could also be that the parser picks up a non generic
> overload from another unit (due to the order of units in the uses section)
> and then you can *only* handle that in tcallcandidates.
>
Hmmm, I
Ryan Joseph schrieb am Di., 8. Okt. 2019, 23:00:
>
>
> > On Oct 8, 2019, at 11:32 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > I checked again. The thing is that in the compiler overload handling is
> done inside htypechk.tcallcandidates. Your patch
> On Oct 8, 2019, at 11:32 AM, Sven Barth via fpc-pascal
> wrote:
>
> I checked again. The thing is that in the compiler overload handling is done
> inside htypechk.tcallcandidates. Your patch weakens/changes that. So you'll
> have to completely rethink your solution to fit it into
Ryan Joseph schrieb am Fr., 4. Okt. 2019, 17:10:
>
>
> > On Oct 3, 2019, at 6:07 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > A patch for it by Ryan Joseph exists (
> https://bugs.freepascal.org/view.php?id=35261 ), but I've not yet found
> the time to review
On Mon, 7 Oct 2019 16:35:42 -0400
Ryan Joseph wrote:
>[...]
> procedure Run(a: integer; b: string);
> begin
> end;
>
> generic procedure Run(a: S; b: T; c: integer);
> begin
> end;
>
>
> // fails because the non-generic Run() will always be picked and the
> parameter count will be wrong.
> On Oct 7, 2019, at 12:42 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
>> I mean what happens here? The non-generic functions wins right?
>>
>> procedure Run(a:T; b: word);
>> procedure Run(a: word; b: T);
>> procedure Run(a: word; b: word);
>
> Only for
> Run(word(1),word(2));
Ok, then
On Mon, 7 Oct 2019 19:47:58 +0200
Sven Barth via fpc-pascal wrote:
> Mattias Gaertner via fpc-pascal
> schrieb am Mo., 7. Okt. 2019, 18:42:
>
> > On Mon, 7 Oct 2019 12:38:51 -0400
> > Ryan Joseph wrote:
> >
> > > > On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal
> > > > wrote:
Mattias Gaertner via fpc-pascal schrieb
am Mo., 7. Okt. 2019, 18:42:
> On Mon, 7 Oct 2019 12:38:51 -0400
> Ryan Joseph wrote:
>
> > > On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal
> > > wrote:
> > >
> > > Note that in Delphi the "non-generic-wins" rule is per parameter:
> > >
>
On Mon, 7 Oct 2019 12:38:51 -0400
Ryan Joseph wrote:
> > On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal
> > wrote:
> >
> > Note that in Delphi the "non-generic-wins" rule is per parameter:
> >
> > procedure Run(a:T; b: word);
> > procedure Run(a: word; b: T);
>
> I mean what
> On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Note that in Delphi the "non-generic-wins" rule is per parameter:
>
> procedure Run(a:T; b: word);
> procedure Run(a: word; b: T);
I mean what happens here? The non-generic functions wins right?
procedure Run(a:T;
Ryan Joseph schrieb am Mo., 7. Okt. 2019, 15:51:
> That bug aside the rule is that non-generic overloads always win over
> generics. I remember this was discussed at length if we can find the old
> thread.
>
Here:
https://lists.freepascal.org/pipermail/fpc-pascal/2018-December/055225.html
On Mon, 7 Oct 2019 09:38:45 -0400
Ryan Joseph wrote:
>[...]
> > This means you don't support:
> > generic procedure Run(a: T; b:S); overload;
>
> That’s correct, this breaks the logic entirely. This to me looks like
> a sneaky way to trick the compiler and since it’s trying to infer
>
On Mon, 7 Oct 2019 09:51:47 -0400
Ryan Joseph wrote:
> Right now this gives an error because you can’t add normal functions
> AFTER generic functions with the same name in the same scope. I can’t
> find the bug report but I think Sven fixed this recently or gave a
> better error at least.
I
On Mon, 7 Oct 2019 15:37:46 +0200 (CEST)
Michael Van Canneyt wrote:
>[...]
> > You mean, if a bad overload can be nullified by a good one? That
> > would be insane...
> >
> > Yes, Delphi eats it without warning.
> >
> > And it works even with a generic param:
> >
> > generic function Run(a: T;
> On Oct 7, 2019, at 1:54 AM, Sven Barth via fpc-pascal
> wrote:
>
> There is nothing debatable here. If a generic parameter is not used in the
> parameter list (cause it's used in the result type (either directly or to
> specialize something else), only the body of the routine or even not
Right now this gives an error because you can’t add normal functions AFTER
generic functions with the same name in the same scope. I can’t find the bug
report but I think Sven fixed this recently or gave a better error at least.
generic function DoThis(a: T): T; overload;
begin
end;
generic
> On Oct 7, 2019, at 5:39 AM, Mattias Gaertner via fpc-pascal
> wrote:
>
> I'm baffled. That's more basic algorithm than I expected. ;)
All contributions are welcome. It sounds like we need make some changes or
overhaul the entire thing.
>
> This means you don't support:
> generic
On Mon, 7 Oct 2019, Mattias Gaertner via fpc-pascal wrote:
Should the compiler choose the 3rd non-generic function, or still
give an error ?
You mean, if a bad overload can be nullified by a good one? That would
be insane...
Yes, Delphi eats it without warning.
And it works even with a
On Mon, 7 Oct 2019 14:37:16 +0200 (CEST)
Michael Van Canneyt wrote:
> On Mon, 7 Oct 2019, Mattias Gaertner via fpc-pascal wrote:
>
>[...]
> I think sven means if you have e.g. 3 functions:
>
> generic function DoThis(a: T): T; overload;
> begin end;
>
> generic function DoThis(a: T): U;
On Mon, 7 Oct 2019, Mattias Gaertner via fpc-pascal wrote:
On Mon, 7 Oct 2019 14:12:32 +0200
Sven Barth via fpc-pascal wrote:
[...]
> > > > generic function DoThis(a: T): T; overload;
> > > > begin end;
> > > > generic function DoThis(a: T): U; overload;
> > > > begin end;
> > > >
> > > >
On Mon, 7 Oct 2019 14:12:32 +0200
Sven Barth via fpc-pascal wrote:
>[...]
> > > > > generic function DoThis(a: T): T; overload;
> > > > > begin end;
> > > > > generic function DoThis(a: T): U; overload;
> > > > > begin end;
> > > > >
> > > > > begin
> > > > > DoThis(3); // both fits, should
Mattias Gaertner schrieb am Mo., 7. Okt. 2019,
11:59:
> On Mon, 7 Oct 2019 07:54:51 +0200
> Sven Barth via fpc-pascal wrote:
>
> > Ryan Joseph schrieb am Mo., 7. Okt. 2019,
> > 00:16:
> >[...]
> > > >>> 3.
> > > >>> timpfuncspez2.pp
> > > >>> DoThis
> > > >>> DoThis
> > > >>> Delphi gives an
On Mon, 7 Oct 2019 07:54:51 +0200
Sven Barth via fpc-pascal wrote:
> Ryan Joseph schrieb am Mo., 7. Okt. 2019,
> 00:16:
>[...]
> > >>> 3.
> > >>> timpfuncspez2.pp
> > >>> DoThis
> > >>> DoThis
> > >>> Delphi gives an error "Ambiguous call to DoThis". FPC silently
> > >>> selects the one with
On Sun, 6 Oct 2019 18:16:16 -0400
Ryan Joseph wrote:
>[...]
> I think my logic is different from what you expect though and I’m
> happy to change it if we need to.
>
> There’s the comment I left in the code for the
> “try_implicit_specialization” function.
>
> { find generic procsyms by
On Sun, 6 Oct 2019 18:16:16 -0400
Ryan Joseph wrote:
>[...]
> >>> 3.
> >>> timpfuncspez2.pp
> >>> DoThis
> >>> DoThis
> >>> Delphi gives an error "Ambiguous call to DoThis". FPC silently
> >>> selects the one with only one param. IMO this is dangerous, it
> >>> should give an error.
> >
> >
On Sun, 6 Oct 2019 18:16:16 -0400
Ryan Joseph wrote:
> > On Oct 6, 2019, at 5:40 PM, Mattias Gaertner via fpc-pascal
> > wrote:
> >> Which test? Please post a sample.
> >
> > generic procedure DoThis(a:T; b:T);
> > begin end;
> >
> > begin
> > DoThis(1,200); // 1 sets T to shortint, so
On Sun, 6 Oct 2019 18:19:37 -0400
Ryan Joseph wrote:
>[...]
> That works then. Added a test:
> [...]
Thanks.
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Ryan Joseph schrieb am Mo., 7. Okt. 2019, 00:16:
>
> >
> >>> 3.
> >>> timpfuncspez2.pp
> >>> DoThis
> >>> DoThis
> >>> Delphi gives an error "Ambiguous call to DoThis". FPC silently
> >>> selects the one with only one param. IMO this is dangerous, it
> >>> should give an error.
> >
> > generic
> On Oct 6, 2019, at 5:42 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> I meant:
>
> generic procedure DoThis(param1: T; param2: word = 100);
> begin
> end;
That works then. Added a test:
{$mode objfpc}
{$modeswitch implicitfunctionspecialization}
program timpfuncspez15;
generic
> On Oct 6, 2019, at 5:40 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
>> Which test? Please post a sample.
>
> generic procedure DoThis(a:T; b:T);
> begin end;
>
> begin
> DoThis(1,200); // 1 sets T to shortint, so the 200 gives a warning
> end;
>
What is the preferred behavior? I’m
On Sun, 6 Oct 2019 17:10:54 -0400
Ryan Joseph wrote:
> > On Oct 6, 2019, at 5:03 PM, Ryan Joseph
> > wrote:
> >> On Oct 6, 2019, at 2:06 PM, Mattias Gaertner via fpc-pascal
> >> wrote:
> >>
> >> 1.
> >> FPC allows default params, Delphi does not. Nice.
> >> I see no tests for this though, so
On Sun, 6 Oct 2019 17:03:10 -0400
Ryan Joseph wrote:
>[...]
> > 2.
> > DoThis(1,200) gives range check warning instead of error. A warning
> > means there are some rare cases, where this code is correct. Is
> > this a todo or do you see a useful case?
>
> Which test? Please post a sample.
> On Oct 6, 2019, at 5:03 PM, Ryan Joseph wrote:
>
>> On Oct 6, 2019, at 2:06 PM, Mattias Gaertner via fpc-pascal
>> wrote:
>>
>> 1.
>> FPC allows default params, Delphi does not. Nice.
>> I see no tests for this though, so maybe this was not on purpose?
>
> Probably an oversight if you
Thanks for testing. I don’t have access to Delphi so I need help to make it
Delphi compatible.
> On Oct 6, 2019, at 2:06 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> 1.
> FPC allows default params, Delphi does not. Nice.
> I see no tests for this though, so maybe this was not on purpose?
On Sun, 6 Oct 2019 12:23:57 -0400
Ryan Joseph wrote:
> > On Oct 6, 2019, at 12:18 PM, Mattias Gaertner via fpc-pascal
> > wrote:
> >
> > Ryan, is patch_3_25.diff the latest patch?
> >
> > I get a lot of merge conflicts.
> > What fpc revision is needed for this?
> >
> > And what is the git
> On Oct 6, 2019, at 12:18 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Ryan, is patch_3_25.diff the latest patch?
>
> I get a lot of merge conflicts.
> What fpc revision is needed for this?
>
> And what is the git repo
> https://github.com/genericptr/freepascal/tree/generic_implicit
>
On Fri, 4 Oct 2019 11:10:22 -0400
Ryan Joseph wrote:
> > On Oct 3, 2019, at 6:07 PM, Sven Barth via fpc-pascal
> > wrote:
> >
> > A patch for it by Ryan Joseph exists
> > ( https://bugs.freepascal.org/view.php?id=35261 ), but I've not yet
> > found the time to review it.
>
> I’m eager to use
Ryan Joseph schrieb am Fr., 4. Okt. 2019, 17:10:
>
>
> > On Oct 3, 2019, at 6:07 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > A patch for it by Ryan Joseph exists (
> https://bugs.freepascal.org/view.php?id=35261 ), but I've not yet found
> the time to review
> On Oct 3, 2019, at 6:07 PM, Sven Barth via fpc-pascal
> wrote:
>
> A patch for it by Ryan Joseph exists (
> https://bugs.freepascal.org/view.php?id=35261 ), but I've not yet found the
> time to review it.
>
I’m eager to use this also but it’s been sitting there for about 6 months now,
Mattias Gaertner via fpc-pascal schrieb
am Do., 3. Okt. 2019, 21:35:
> Hi,
>
> What is the state of FPC support for calling generic procedures using
> inference like Delphi?
>
> For example:
>
> {$mode objfpc}
> generic procedure Run(a: T);
> begin
> end;
>
> begin
> Run(2);
> end.
>
A patch
Hi,
What is the state of FPC support for calling generic procedures using
inference like Delphi?
For example:
{$mode objfpc}
generic procedure Run(a: T);
begin
end;
begin
Run(2);
end.
Mattias
___
fpc-pascal maillist -
45 matches
Mail list logo
