[fpc-devel] Explicitly named return values and implicit aliases Result

2020-12-15 Thread Blaise--- via fpc-devel
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

Re: [fpc-devel] Explicitly named return values and implicit aliases Result

2020-12-16 Thread Blaise--- via fpc-devel
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

Re: [fpc-devel] Explicitly named return values and implicit aliases Result

2020-12-16 Thread Blaise--- via fpc-devel
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

[fpc-devel] Method pointers to RECORD methods

2020-12-16 Thread Blaise--- via fpc-devel
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;

[fpc-devel] Generic instantiations as result types of procedural types

2020-12-16 Thread Blaise--- via fpc-devel
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'

[fpc-devel] Procedural types returning file types

2020-12-18 Thread Blaise--- via fpc-devel
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

[fpc-devel] Local classes and interfaces

2020-12-19 Thread Blaise--- via fpc-devel
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;

Re: [fpc-devel] Local classes and interfaces

2020-12-21 Thread Blaise--- via fpc-devel
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

[fpc-devel] Parsing procedural type and method directives

2021-12-21 Thread Blaise--- via fpc-devel
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

[fpc-devel] Assigning class methods, accessed via a class reference type, to procvars

2021-12-22 Thread Blaise--- via fpc-devel
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

[fpc-devel] Assigning class non-static methods, accessed via a helper type, to method pointers

2021-12-23 Thread Blaise--- via fpc-devel
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

[fpc-devel] Assigning instance methods, accessed via a type, to method pointers

2021-12-23 Thread Blaise--- via fpc-devel
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

[fpc-devel] Assigning class methods, accessed via an object or helper type, to incompatible procvars

2021-12-23 Thread Blaise--- via fpc-devel
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

[fpc-devel] Initialising method pointers with class methods

2021-12-23 Thread Blaise--- via fpc-devel
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

[fpc-devel] $modeswitch Closures

2021-12-25 Thread Blaise--- via fpc-devel
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

[fpc-devel] Functors

2021-12-25 Thread Blaise--- via fpc-devel
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

Re: [fpc-devel] Functors

2021-12-26 Thread Blaise--- via fpc-devel
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

Re: [fpc-devel] Functors

2021-12-26 Thread Blaise--- via fpc-devel
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

Re: [fpc-devel] Functors

2021-12-26 Thread Blaise--- via fpc-devel
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

Re: [fpc-devel] Functors

2021-12-26 Thread Blaise--- via fpc-devel
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:

Re: [fpc-devel] Functors

2021-12-26 Thread Blaise--- via fpc-devel
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

Re: [fpc-devel] Functors

2021-12-26 Thread Blaise--- via fpc-devel
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,

Re: [fpc-devel] Functors

2021-12-26 Thread Blaise--- via fpc-devel
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