the first reply to this
thread. Allow me to quote my response:
On 26.12.2021 15:40, Blaise--- via fpc-devel wrote:
On 26.12.2021 11:50, Michael Van Canneyt via fpc-devel wrote:
As I see it, it's just shorthand syntax to allow skipping the name 'Invoke'.
None of what is shown
On 27.12.2021 0:57, Martin Frb via fpc-devel wrote:
writeln( aC(33) );
aC('hello');
the above examples are probably intended to show the syntax. But not indented
to show any useful application?
The test you quoted demonstrates what is already possible, syntactically and
semantically,
On 27.12.2021 0:03, Michael Van Canneyt via fpc-devel wrote:
On Sun, 26 Dec 2021, Blaise--- via fpc-devel wrote:
On 26.12.2021 19:33, Michael Van Canneyt via fpc-devel wrote:
On Sun, 26 Dec 2021, Blaise--- via fpc-devel wrote:
following your reasoning, the same should be said about
On 26.12.2021 23:47, Blaise--- via fpc-devel wrote:
---8<---
type R = record
procedure Foo(...); operator ();
function Bar(const A, B: R): R; operator +;
end;
---8<---
Made a blunder there, sorry: for Bar, it should either be
function Bar(const Other:
On 26.12.2021 19:33, Michael Van Canneyt via fpc-devel wrote:
On Sun, 26 Dec 2021, Blaise--- via fpc-devel wrote:
On 26.12.2021 11:50, Michael Van Canneyt via fpc-devel wrote:
None of what is shown below cannot be handled by ordinary methods
Well, yes. But, following your reasoning, the same
On 26.12.2021 17:40, Ryan Joseph via fpc-devel wrote:
I'm 99% certain using the method name "Invoke" would be rejected on the grounds
of backwards compatibility.
Not to argue for the "procedure/function Invoke" syntax, but it hardly breaks backward
compatibility. Only in the purest non-practi
On 26.12.2021 11:50, Michael Van Canneyt via fpc-devel wrote:
Please explain what's the point or benefit of this.
Do you mean "in general", or "specifically to FPC"?
A) In general: I reckon that the article covers the matter quite well; I have
nothing to add.
B) Specifically for FPC: it is up
I propose that the support for https://en.wikipedia.org/wiki/Function_object be
added to the FPC.
A subset of such functionality already existed as a part of my implementation
of closures, so I extended that part to implement the core feature for allowing
functors -- overloading of the call op
The attached modeswitch_closures.patch introduces {$modeswitch Closures}; it is
included in {$mode Delphi}.
There is a distinction between anonymous routines (defined in-place, without a
name) and closures (capture the context they are invoked with). The switch
encompasses both, but goes for t
DCC allows the subj (provided that the class type is known at compile time),
FPC does not.
The attached init_methptr_with_classmeth.patch implements this feature.
---8<---
type C = class
class procedure Foo;
end;
class procedure C.Foo; begin end;
type CC = class of C;
type H = c
On 22.12.2021 21:16, Blaise wrote:
1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error
reported for:
[ICE] Assigning class methods, accessed via a class reference type, to
incompatible procvars
Also fixes:
1B) [ICE] Assigning class static methods, accessed via an object
Subj silently produces invalid codegen:
---8<---
var Z: procedure of object;
type R = record
procedure Foo;
end;
procedure R.Foo; begin end;
type O = object
procedure Foo;
end;
procedure O.Foo; begin end;
type C = class
procedure Foo;
class procedure Clas
Subj silently produces invalid codegen:
---8<---
type C = class end;
type H = class helper for C
class procedure Bar;
end;
class procedure H.Bar;
begin
writeln('H.Bar(self=', ClassName, ')')
end;
var Z: procedure of object;
begin
Z := H.Bar; // BadCG: GARBAGE
1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error
reported for:
[ICE] Assigning class methods, accessed via a class reference type, to
incompatible procvars
---8<---
type C = class
class procedure NonStatic;
class procedure Static; static;
end;
cl
1) The following three routines:
pdecsub.pas!parse_parameter_dec
pdecvar.pas!maybe_parse_proc_directives
ptype.pas!read_named_type\procvar_dec
create a dummy typesym for the procdef, for the sole purpose of invoking
parse_var_proc_directives, which merely extracts that pro
On 19.12.2020 16:51, Sven Barth wrote:
Considering that it's only intended for internal use, yes I'm aboard with that.
Here is the first change: http://hg.blaise.ru/public/fpc/rev/7c78bfdaed9a
(attached).
Strictly speaking, some local classes and interfaces can be compiled without
that -- th
Behind the scene, the Closures implementation declares classes and interfaces.
And, because I strongly believe it to be conceptually the right way, such
entities are declared in the innermost routine scope. For example,
---8<---
procedure Foo;
type Local = reference to procedure;
The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) fixes the
following:
---8<---
// EXPECTED: 'Error: Illegal function result type'
// ACTUAL: gets compiled
type M = function : file;
begin
end.
---8<---
--
βþ
# HG changeset patch
# User Blaise.ru
# Date 1608281
The patch http://hg.blaise.ru/public/fpc/rev/544a934d262e (attached) fixes the
following:
---8<---
{$Mode Delphi}
type G = class
var X: T;
// EXPECTED: gets compiled
// ACTUAL: 'Error: Generics without specialization cannot be used as a
type for a variable'
The patch http://hg.blaise.ru/public/fpc/rev/0a8aff8d8273 (attached) fixes the
following:
---8<---
{$Mode Delphi}
type R = record
var X: Integer;
function Foo: Integer;
end;
function R.Foo: Integer;
begin
result := X
end;
var F: function : Integer of object;
On 16.12.2020 12:24, Michael Van Canneyt via fpc-devel wrote:
To be correct: Result is not the name of the result value, it is an alias.
I did not dispute that. The important point here is: "an alias" to /what/?
You can still use the function name for the result, so "Result" is in fact an
al
On 16.12.2020 0:07, Sven Barth wrote:
No, those two are in fact correct this way.
Is that the /team's/ consensus?
The modeswitch Result enables the use of Result as an alias for *any* routine …
Incorrect. The identifier Result does not alias the routine, it aliases the
routine's return val
Consider this test case:
---8<---
{$mode ObjFPC}
// EXPECTED: 'Error: Identifier not found "result"'
// ACTUAL BUG #1: gets compiled
operator - (const L, R: Char) returned: Char;
begin
result := 'Z'
end;
// EXPECTED: gets compiled
// ACTUAL BUG #2: 'Error: Duplicate identifier "r
23 matches
Mail list logo
