> On Jun 1, 2019, at 6:00 AM, Michael Van Canneyt
> wrote:
>
> I don't think this syntax is a good idea.
>
> What with overloads ?
>
> Procedure MyProc(a:T);
> Procedure MyProc(a : TObject);
Currently the non-generic gets called in this situation. That’s because
non-generic procedures take
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
operato...@gmail.com sent:
> On Sat, Jun 1, 2019
On Sat, Jun 1, 2019 at 10:58 AM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> 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 freestandi
On Sat, Jun 1, 2019 at 6:00 AM Michael Van Canneyt
wrote:
> I don't think this syntax is a good idea.
>
> What with overloads ?
>
> Procedure MyProc(a:T);
> Procedure MyProc(a : TObject);
>
> How do I know which one will be called ?
>
I think it would have to work like: if something is a TObject
On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote:
Michael Van Canneyt schrieb am Sa., 1. Juni 2019,
14:13:
On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote:
specialize ClearMem(pt);
With implicit specialization:
ClearMem(pt); // :)
I don't think this syntax is a good idea
Michael Van Canneyt schrieb am Sa., 1. Juni 2019,
14:13:
>
>
> On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote:
>
> >>>
> >>> specialize ClearMem(pt);
> >>>
> >>> With implicit specialization:
> >>>
> >>> ClearMem(pt); // :)
> >>
> >> I don't think this syntax is a good idea.
> >>
> >
>
Hi,
I started to write a driver (
https://github.com/dioannidis/fp_ethernet_enc28j60.git ) for this chip (
ENC28J60 Ethernet Controller ) first for the AVR platform, ( heavily
inspired from the UIPEthernet library (
https://github.com/UIPEthernet/UIPEthernet.git )) and I want to ask the
co
>> 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 fact, we already have several bug reports related to overloading/gen
On Sat, 1 Jun 2019, denisgolovan wrote:
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
On Sat, 1 Jun 2019, Sven Barth via fpc-devel wrote:
specialize ClearMem(pt);
With implicit specialization:
ClearMem(pt); // :)
I don't think this syntax is a good idea.
It's required for Delphi compatibility.
Indeed. It gets worse by the day :(
Michael.
___
Michael Van Canneyt schrieb am Sa., 1. Juni 2019,
12:00:
>
>
> On Fri, 31 May 2019, Ryan Joseph wrote:
>
> >
> >
> >> 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 so
> 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 cl
On Sat, 1 Jun 2019, Martok wrote:
What with overloads ?
Procedure MyProc(a:T);
Procedure MyProc(a : TObject);
How do I know which one will be called ?
Once again: FPC needs a defined method resolution order, *and stick with it*.
The current ad-hoc inheritance/typeconv/:= overload/overload
> What with overloads ?
>
> Procedure MyProc(a:T);
> Procedure MyProc(a : TObject);
>
> How do I know which one will be called ?
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 a
On Fri, 31 May 2019, Ryan Joseph wrote:
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 swit
15 matches
Mail list logo
