Am 03.12.2018 um 14:01 schrieb Ryan Joseph:
On Dec 3, 2018, at 2:45 PM, Ryan Joseph wrote:
I just looked it over and I was wrong about the dummy, it’s just a flag. If the
generic doesn’t cover existing functions then that messes up some assumptions I
made so I need re-think the design now.
> On Dec 3, 2018, at 9:10 PM, Martok wrote:
>
> What happens when there are implicit conversion operators defined?
> I.e.:
>
>operator := (x: integer): string;
>// with and without this more specific overload:
>procedure DoThis(msg:integer);overload;
>generic procedure DoThis(m
Am 03.12.2018 um 14:01 schrieb Ryan Joseph:
> I believe I managed to solve the problem and now non-generic procedures take
> precedence. I guess it’s possible that you could opt out of an implicit
> specialization now but declaring and overload which the specific type you
> were interested in. T
> On Dec 3, 2018, at 2:45 PM, Ryan Joseph wrote:
>
> I just looked it over and I was wrong about the dummy, it’s just a flag. If
> the generic doesn’t cover existing functions then that messes up some
> assumptions I made so I need re-think the design now.
I believe I managed to solve the pr
> On Dec 3, 2018, at 1:59 PM, Sven Barth via fpc-pascal
> wrote:
>
> The dummy symbol should only be created if there isn't an existing symbol
> with that name. So maybe something is buggy there. (Also the dummy symbol
> should be used for a non-generic routine if the order of declaration is
Am Mo., 3. Dez. 2018, 03:45 hat Ryan Joseph
geschrieben:
>
>
> > On Dec 2, 2018, at 10:53 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Specialization is expensive. If specialization can be avoided, it should
> be. Not to mention that the non-generic one could
> On Dec 2, 2018, at 10:53 PM, Sven Barth via fpc-pascal
> wrote:
>
> Specialization is expensive. If specialization can be avoided, it should be.
> Not to mention that the non-generic one could have more optimized code.
> Though to be sure I'll test with Delphi, we'll have to be compatible
Am So., 2. Dez. 2018, 15:28 hat Ryan Joseph
geschrieben:
>
>
> > On Dec 2, 2018, at 8:11 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Also the idea should be that a non-generic routine takes precedence.
> >
>
> I did this wrong then because the generic takes p
I just tested and my code has the same behavior as the explicit specialization
(as expected), i.e. last wins, regardless of generic status.
procedure DoThis(msg:integer);
begin
writeln('DoThis:',msg);
end;
generic procedure DoThis(msg:T);
begin
writeln('DoThis$1#1:',msg);
end;
b
> On Dec 2, 2018, at 8:11 PM, Sven Barth via fpc-pascal
> wrote:
>
> Also the idea should be that a non-generic routine takes precedence.
>
I did this wrong then because the generic takes precedence now. Why shouldn’t
the generic take precedence though? It comes after so you think it would
Hi Sven
> Where is it messy? O.o
See https://bugs.freepascal.org/view.php?id=28824
> Also the idea should be that a non-generic routine takes precedence.
Seems reasonable.
--
Regards,
Denis Golovan
___
fpc-pascal maillist - fpc-pascal@lists.freep
Am So., 2. Dez. 2018, 10:55 hat denisgolovan
geschrieben:
> Hi Ryan
>
> That's definitely a nice feature.
> Could you clarify and/or discuss with compiler devs the rules for function
> overloads?
> Currently FPC seems a bit messy even without inferencing like that.
>
Where is it messy? O.o
Also
Hi Ryan
That's definitely a nice feature.
Could you clarify and/or discuss with compiler devs the rules for function
overloads?
Currently FPC seems a bit messy even without inferencing like that.
BR,
Denis
___
fpc-pascal maillist - fpc-pascal@lists.
13 matches
Mail list logo
