Re: [fpc-devel] Plans for 2022
> On Jan 9, 2022, at 2:09 PM, J. Gareth Moreton via fpc-devel > wrote: > > https://www.patreon.com/posts/60922821 Your plans are vectorization are an important gain for linear algebra and games. Could you detect things like: var a, b, c: TVec2; begin c := a + b * V2(10, 10); where the vec2 type has operator overloads for common operations? This kind of thing is very common in graphics math and I bet there's some clever ways you could compress that operation down. Curious how the C++ compilers do this also... Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Functors
> On Dec 27, 2021, at 1:44 AM, bla...@blaise.ru wrote: > > So, in your book, introducing a /new/ operator identifier "doesn't present > any new syntax" (and I agree), but semantically allowing the /existing/ > directive DEFAULT to appear in the existing list of method directives is > somehow "a new syntax". You have some interesting definition of "syntax". I was mainly just trying to predict what Sven will say because I've proposed so many things over the recent years. :) "Default" has never been used outside of properties which is why it could be considered "new syntax". As for the idea of a "call operator" that would require "self" to be passed in as the first param (like record management operators) AND "class operator" is not allowed in classes right now so this would limit it to records only. I already tried to get Sven to accept class operators on classes (for some operators only) and this was rejected. Given that I would say this would indeed go the way of properties since it's a form of aliasing or re-routing: property Invoke: T read DoInvoke; default; However I have already made a patch (nearly finished) for a "default record property" which does something similar to this (it's meant for smart pointers like how C++ overloads the -> operator) and even though Sven did seem behind the idea I don't see he's been willing to follow up on it. Not sure what this means for the feature or if it will ever be accepted. https://gitlab.com/genericptr/free-pascal/-/tree/default_record_property So if there is now a default method it would confound this idea even further and it's already not clear if FPC will accept this kind of thing. I'm not saying any of this to discourage the idea though since I think it's interesting. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Functors
> On Dec 26, 2021, at 3:50 PM, Michael Van Canneyt via fpc-devel > wrote: > > Please explain what's the point or benefit of this. To aid in the usage of classes that have the sole intent of being called. Surely though the compiler team will say this is not *needed* and can be achieved using normal method calls. Question to Blaise, how is this adjacent to closures? I just see it as an operator overload, i.e. how C++ allows to overload the () operator. I will also say In my attempt to make a "default property" which could be used for smart pointers Sven specially said absolutely no to the idea of overloading the "." operator so I tend to think this idea won't go far. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Functors
> On Dec 26, 2021, at 3:50 PM, Michael Van Canneyt via fpc-devel > wrote: > > I think the idea of using a fixed member identifier for special purposes is > really > stupid design. I'll never forgive Embarcadero their 'GetEnumerator' idea... I'm 99% certain using the method name "Invoke" would be rejected on the grounds of backwards compatibility. Adding a new syntax using "default" like "function Add9(const N: Integer): Integer; default;" would probably be rejected on the grounds that it's new syntax alone (that is default is only used with properties currently). I would say an operator would be most likely to be accepted, such as: class operator Call(); because it could be overloaded easily and doesn't present any new syntax. Personally I like this idea but I tend to favor new syntaxes. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assigning class methods, accessed via a class reference type, to procvars
Thank you for continuing work on this, we all really appreciate your efforts. > On Dec 23, 2021, at 1:16 AM, Blaise--- via fpc-devel > wrote: > > 1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error > reported for: Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM backend Pascal bindings?
> On Nov 14, 2021, at 4:58 PM, Jonas Maebe via fpc-devel > wrote: > > Afaik there's also a C binding (or at least there used to be one). There is some c bindings but they seem incomplete, or at least I couldn't figure out how to follow the tutorial using what was provided there. > >> How did Free Pascal/Jonas accomplish this in the LLVM backend? > > FPC generates LLVM IR which is then compiled using clang. It does not link to > the LLVM libraries in any way. > That's what I thought but that's certainly beyond the scope of what I could do. :) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] LLVM backend Pascal bindings?
As a fun weekend project I wanted to follow along with the tutorial at https://llvm.org/docs/tutorial/index.html but I noticed the API in in C++ so it wouldn't be possible to do this in Pascal without at least some plain C API. How did Free Pascal/Jonas accomplish this in the LLVM backend? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI status in 3.2.0 and 3.2.2
> On Sep 19, 2021, at 7:01 AM, Sven Barth via fpc-devel > wrote: > > No, this is not yet supported, but it's a work in progress, but it will > arrive the earliest with 3.4 which is not yet planned. > We're nearly finished with right now so it could appear in the trunk version within a month or so even. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Moving to gitlab.
I see the old bug reporter has been taken down now. Can anyone explain how to see my old bug reports now? I went to https://gitlab.com/groups/freepascal.org/fpc/-/issues and filtered by my username "genericptr" but nothing came up. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] To all Mantis (Bugtracker) account holders - prepare for the move to Gitlab - Now
> On Jul 17, 2021, at 4:09 PM, Michael Van Canneyt via fpc-devel > wrote: > > Yes. ok, thanks. https://bugs.freepascal.org/view.php?id=39238 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] To all Mantis (Bugtracker) account holders - prepare for the move to Gitlab - Now
> On Jul 17, 2021, at 12:58 PM, Michael Van Canneyt via fpc-devel > > > To map your gitlab user name (or ID) to the > mantis user, we ask that you file an issue in the mantis project of the > current bugtracker > https://bugs.freepascal.org/bug_report_page.php?project_id=4 > Assign it the category gitlab, and set the summary of > the bugreport to your gitlab account name or ID number (not both!). I signed in with GitLab using my GitHub account (where may user name is @genericptr). Does that mean simply file a report with the "summary" field containing "genericptr"? I guess this process is automated. I have a number of open reports I'd like transferred over. Does this mean the Mantis reporter is going be shut down or are users simply encouraged to not post new reports there? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC & Lazarus moving to gitlab
> On Jun 22, 2021, at 4:02 PM, Sven Barth wrote: > > The plan has *never* been GitHub. The original plan was self hosted with a > *mirror* on GitHub. Now we'll instead use GitLab as main repository with a > mirror on GitHub. > How does the mirroring work? It seems 99% of the dev world is using GitHub now so it's a pity to have to learn new tools if we don't have to. I'm very happy with GitHub myself and use it often. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC & Lazarus moving to gitlab
> On Jun 22, 2021, at 10:05 AM, Michael Van Canneyt via fpc-devel > wrote: > > The date for the final conversion has been established as the weekend of > 17/18 july. People that wish to report bugs after that will have to create a > gitlab account in order to do so. (Those with a github account can normally > also use that account to log in with gitlab, see the gitlab login page.) I thought the plan was to move to GitHub? I never used GitLab before so can you explain the reasoning here? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 10, 2021, at 3:18 PM, Ryan Joseph wrote: > > Lets focus on the record approach for now then. I don't think I know enough > to understand where are the pitfalls are. This was another thing I wanted off my mind since a couple years ago already so I got a pretty good start of an implementation. Since Sven has made it pretty clear we can't add ARC to Pascal without altering all instances of TObject, this is the next best thing. Together with record management operators this is how we can achieve "smart pointers" in Pascal. I've constrained the implementation to hoisting the following members: * Fields (duplicate field names with the record gives errors) * Properties (last-wins, like in class hierarchies) * Methods (and overloading with the method itself) * for..in enumerator so container classes can be used naturally (other operators are not supported to keep the implementation simple for 99% use cases) * Hoisting happens only by subscripting from the outside, so not within the record using implicit-self. * Only records + classes are supported types (in the interest of keep the feature for ARC and not other things like nullable types or traits/mix-ins etc...) https://bugs.freepascal.org/view.php?id=38872 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On May 15, 2021, at 10:49 AM, Ryan Joseph wrote: > > Also it looks like ChangeOwnerAndName isn't making the compiler happy. Sorry for the noise, I figured out it was because the name had spaces. How should I make the name then? I'm doing this for now which is certainly unique but it's not standard. newtype:=ctypesym.create(def.fullownerhierarchyname(false)+typName[def.typ]+'$'+def.unique_id_str,def); It will make names like below which don't upset the assembler. SOMETESTUNIT.arraydef$5 Anyways, I put up a patch on the bug tracker (https://bugs.freepascal.org/view.php?id=35261) for you to review and see if I did this right. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On May 15, 2021, at 10:27 AM, Ryan Joseph wrote:
>
> Looking at this again today and I have yet another question to confirm. I
> create one of the types using ctypesym.create but the others were just
> references from the system unit. We only want to change owner of the symbol I
> create, right? Not the system unit ones? If not changing owner maybe we need
> to add some ref count or something? just confirming to make sure.
Also it looks like ChangeOwnerAndName isn't making the compiler happy.
The dynamic array creates an unnamed typesym like this. (def is the array def
for [1,2,3])
newtype:=ctypesym.create(def.typename,def);
newtype.owner:=def.owner;
And specialized like this:
generic procedure DoThis(p1: T);
begin
end;
begin
DoThis([1,2,3]);
end;
Then during assembling I get these errors.
Assembling (pipe)
/Users/ryanjoseph/Developer/Projects/FPC/macro_test/output/timpfuncspez0.s
:40:50: error: unexpected token in directive
.globl _P$TIMPFUNCSPEZ19_$$_DOTHIS$1$CRCC2373297${Array Of Const/Constant
Open} Array of ShortInt
^
:41:60: error: unexpected token in directive
.private_extern _P$TIMPFUNCSPEZ19_$$_DOTHIS$1$CRCC2373297${Array Of
Const/Constant Open} Array of ShortInt
^
:42:44: error: unknown token in expression
_P$TIMPFUNCSPEZ19_$$_DOTHIS$1$CRCC2373297${Array Of Const/Constant Open} Array
of ShortInt:
^
:117:50: error: invalid register name
call_P$TIMPFUNCSPEZ19_$$_DOTHIS$1$CRCC2373297${Array Of
Const/Constant Open} Array of ShortInt
^
:117:50: error: Expected an op-mask register at this point
call_P$TIMPFUNCSPEZ19_$$_DOTHIS$1$CRCC2373297${Array Of
Const/Constant Open} Array of ShortInt
^
:283:50: error: unexpected token in '.quad' directive
.quad _P$TIMPFUNCSPEZ19_$$_DOTHIS$1$CRCC2373297${Array Of
Const/Constant Open} Array of ShortInt
^
error: There were 1 errors compiling module, stopping
error: Compilation aborted
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On May 13, 2021, at 2:38 PM, Sven Barth wrote:
>
> Ah, you need to use ChangeOwnerAndName then and simply pass in the same name
> you used for the constructor (cause otherwise it tries to use the name that
> is currently stored in the list).
Looking at this again today and I have yet another question to confirm. I
create one of the types using ctypesym.create but the others were just
references from the system unit. We only want to change owner of the symbol I
create, right? Not the system unit ones? If not changing owner maybe we need to
add some ref count or something? just confirming to make sure.
function create_unamed_typesym(def:tdef): tsym;
var
newtype: tsym;
begin
newtype:=nil;
if is_conststring_array(def) then
begin
{ for constant strings we need to respect various modeswitches }
if (cs_refcountedstrings in current_settings.localswitches) then
begin
if m_default_unicodestring in current_settings.modeswitches
then
newtype:=cunicodestringtype.typesym
else
newtype:=cansistringtype.typesym;
end
else
newtype:=cshortstringtype.typesym;
end
else if def.typ=stringdef then
newtype:=tstringdef(def).get_default_string_type.typesym
else
begin
newtype:=ctypesym.create(def.typename,def);
newtype.owner:=def.owner;
end;
if newtype=nil then
internalerror(2021020904);
result:=newtype;
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On May 9, 2021, at 1:30 AM, Sven Barth wrote: > > Essentially it will boil down to sym.ChangeOwner(pd.parast) > > However you need to keep the Owner (which is different from what you change > with ChangeOwner) different as otherwise is_specialization of the procdef > will not work correctly. > I'm saving the storing symbols in tcallcandiates so they can be available when maybe_add_pending_specialization is called once the call node chooses the specialization, and then I ran into this problem. The symbol I make in create_unamed_typesym has FOwner nil so calling TFPHashObject.ChangeOwner crashes. Did I not make the symbol correctly or do I need to do something before calling ChangeOwner? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 10, 2021, at 5:59 PM, Kostas Michalopoulos via fpc-devel > wrote: > > You do not need any special language feature for that, you can simply do > something like > >ReleaseLater(TObject.Create) yes but we can't get back the reference. It's a small thing but making this possible as return type means we can chain the calls together and make it a one line statement. It's just a nice thing from Objective-C which we use heavily to manage memory and it works very well. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 10, 2021, at 3:05 PM, Sven Barth via fpc-devel > wrote: > > Why should they? You pass the reference to a non-reference counted > parameter/field/variable, the reference count is increased and then what? It > sits there for the remaining life time of the program, because nothing > decrements the reference count? I see what you mean. The FGL containers also call Finalize though when the container is freed so it does indeed keep balanced. Lets focus on the record approach for now then. I don't think I know enough to understand where are the pitfalls are. > You should reread the visibility rules of Object Pascal: > - private: identifier is visible inside the whole unit > - strict private: identifier is only visible inside code of the class > - protected: identifier is visible inside the whole unit as well as inside > descendants of the class as well as type helpers > - strict protected: identifier is visible inside code of the class, inside > descendants of the class as well as type helpers > - public: identifier is visible in the whole unit and (if it's declared in > the interface section) any unit that includes that unit > - published: like public, but with RTTI data yes, yes, I know. I thought we'd do something different. > >> Some things: >> >> 1) What do read/write access even mean in the context of the default >> properties? The terms don't really make much sense given what the the >> property does. Right now the property could be read only or write only but >> those don't really have any affect on the hoisting process itself so it's >> kind of deceptive. Methods are always "read-only" but i guess you could >> hoist fields/properties and inherit the access level of the default >> property. No idea if that's helpful or just adding needless complexity. Any >> ideas? > Property accessors indeed don't really make sense. Maybe a "default field" > would be better than a "default property". "Default field" is certainly more unique and thus better. We'll have to think about this more. > >> 2) I also think there needs to be another name for the feature than "default >> property" since this term is already used for array indexers and could even >> be used for something like traits in the future (traits would be reusing >> much of this code). I need to add some enum names and default_property is >> already used so I need to think of something else. >> >> 3) What about allowing type pointers as default properties? This should be >> possible and is in the spirit of the feature anyways, that is ref counting. >> We may need to add some additional logic to properties (just internally) so >> that they can be used with pointers but I'm not sure about that yet. > Pointers are only useful if the ^ "operator" is hoisted as well. I meant to say pointers to records so yes the ^. would need to be there. I haven't looked into how this would be implemented but I got it working with classes for now. It would be nice to make pointers to records be possible for smart pointers so I'll look into that later. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
Over the weekend I fixed up my old default property code to work with records only which implement classes (which reduced lots of the complexity). It's actually a pretty clean and small implementation so I put a patch you can look at and try. It's not decided upon but this is a place to start should we decide to go this route for "start pointers". https://bugs.freepascal.org/view.php?id=38872 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 9, 2021, at 3:40 AM, Sven Barth wrote:
>
> === code begin ===
>
> {$mode objfpc}
>
> type
> TTest = class
> protected
> procedure DoSomething;
> end;
>
> TTestSub = class refcounted(TTest)
> public
> procedure Test;
> end;
>
> procedure TTest.DoSomething;
> begin
> // maybe this functions stores the reference
> SomeFuncThatTakesAObject(Self);
> end;
>
> procedure TTest.Test;
> begin
> DoSomething;
> end;
>
> === code end ===
I see, the reference counting is broken because you move up into a non-ref
counted class. Yeah that's something programers simply should not do or be
prevented from doing. I don't see this particular case being a problem however
because your ref counted object is going to be in the base of a hierarchy,
probably enforced even. The only reason for opt-in ARC is so we don't pollute
TObject but it still doesn't mean that you should be adding this in the middle
of class trees.
Here is the bigger problem:
var
list: TObjectList;
procedure HandleObject(obj: TObject);
begin
// the list now stores the class but it's lost ref-counting because it was
cast to TObject
list.Add(obj);
end;
var
obj: TTestSub;
begin
HandleObject(obj);
end;
or
var
obj: TObject;
begin
// we lost ref counting now!
obj := TTestSub.Create;
HandleObject(obj);
end;
Once you cast away from your managed class type things fall apart. Records aid
this by not allowing casting but you could enforce some kinds of checks for
managed classes if you wanted to. Doesn't seem like a deal breaker to me if you
add new type rules for passing/assigning.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 9, 2021, at 3:40 AM, Sven Barth wrote: > > It seems that you don't work much with classes then. If one disallows the > assignment of a reference counted class to a non-reference counted one then > you can't use e.g. TStringList.Objects. There is also the problem of method > pointers, which essentially only have a Pointer as Self data. Also a > reference might escape in a parent class (for this example I'll use the > syntax I used in my branch): I use classes all the time but I thought that any assignments or passing to function args call the management operators. So if you pass a managed class to a TStringList.Add for example then AddRef will indeed by called. You're saying this isn't the case? I know the FGL classes can work with ref counted objects so why is it any different if a class type was managed and then passed into one of these types? >> Anyways I wrote up a little wiki with some potential implementation notes >> about a default property (which overlaps on the "defaults implements" as >> traits stuff). Important points are restricting what types can be default >> properties (classes and maybe/probably typed pointers) and limiting hoisting >> to subscripting, so it's kind of like the -> operator overload in C++. >> >> https://github.com/genericptr/freepascal/wiki/Default-property > It shouldn't hoist only public members, it should hoist according to the > visibility rules (thus the hoisting depends on the callsite), otherwise it > won't behave like Pascal classes do and thus we can forget it right away. So this means if the property is in the private section it looks at private visibility in the parent class? Yeah that's probably right we need to do that. Some things: 1) What do read/write access even mean in the context of the default properties? The terms don't really make much sense given what the the property does. Right now the property could be read only or write only but those don't really have any affect on the hoisting process itself so it's kind of deceptive. Methods are always "read-only" but i guess you could hoist fields/properties and inherit the access level of the default property. No idea if that's helpful or just adding needless complexity. Any ideas? 2) I also think there needs to be another name for the feature than "default property" since this term is already used for array indexers and could even be used for something like traits in the future (traits would be reusing much of this code). I need to add some enum names and default_property is already used so I need to think of something else. 3) What about allowing type pointers as default properties? This should be possible and is in the spirit of the feature anyways, that is ref counting. We may need to add some additional logic to properties (just internally) so that they can be used with pointers but I'm not sure about that yet. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On May 8, 2021, at 12:04 PM, Sven Barth wrote: > > You need to use ChangeOwner as well, but as I wrote you need to pay attention > for which created symbol you do it at what time. Ok, maybe this is what I got wrong didn't use ChangeOwner. When you say "add to" what exactly do you mean? Please post a single line code snippet even. Thanks. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 8, 2021, at 11:18 AM, Sven Barth wrote: > > It's not about reference counted classes vs. managed records, but about > whether it's *per type* or *per variable*, the implementation details are > completely irrelevant for now. So the biggest concern you see if that classes are easier to assign to non-reference counted classes? The only difference between classes and records in this regard is that records give errors unless you assign directly to the same record type, where classes can be assigned to super-classes which may not be managed. As you say there would need to be at least a warning if you cast a managed class to another class type or make it forbidden completely. I don't see that as a deal breaker personally but you seem to feel pretty strongly about it. Anyways I wrote up a little wiki with some potential implementation notes about a default property (which overlaps on the "defaults implements" as traits stuff). Important points are restricting what types can be default properties (classes and maybe/probably typed pointers) and limiting hoisting to subscripting, so it's kind of like the -> operator overload in C++. https://github.com/genericptr/freepascal/wiki/Default-property Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 8, 2021, at 8:05 AM, Sven Barth wrote: > >> a := TArray.Create([1,2,3]).AutoRelease; >> >> We can't do this in Pascal because the AutoRelease functions return type is >> not compatible with the type of the caller. Could we add something like an >> "Any" return type to Pascal which is a type that is compatible with any >> class? This relies on an event loop that can capture this garbage and >> dispose of it but it goes a LONG way in helping with common memory >> management problems. > > Dynamic arrays are reference counted, thus you don't need to do any manual > memory management on them. That was a bad example. It's for ANY class really. o := TObject.Create.AutoRelease; Then next event cycle the autorelease pool frees all the objects added to it. Very simple but effective however we can't do this in Pascal without a new permissive return type. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 8, 2021, at 7:59 AM, Sven Barth via fpc-devel > wrote: > > It has the exact same problems that my branch had (especially the interaction > of reference counted instances with non-reference counted ones). > > Using a variable/parameter/field based approach (like the idea with managed > records and default fields) is the more flexible one compared to the type or > instance based one and thus it's more favorable. I still don't understand how the record approach is that much different from a managed class type which calls the same set of management operators. Can we make a pros-cons list to clear this up and give an example of "especially the interaction of reference counted instances with non-reference counted ones"? Here's the most recent things we brought up: - Records can't be cast in a way that would break reference counting (like a managed class being cast to TObject would). - Generic records would create a proliferation of new types for all classes you wanted managed, so instead of using TFPGList you're using TManagedSomeObjectList or TManaged>, or worse yet "specialize TManaged>" Otherwise the same set of circular references exists but I'm not sure about your concern about mixing managed types yet. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 7, 2021, at 2:52 PM, Sven Barth wrote:
>
> As said the main problem of reference counting on object instances,
> especially if enabled by default like the Delphi NextGen compiler did, will
> lead to problems in *existing* code and thus is a no-go.
>
What did you think about me other email that had ideas to add compiler
directives like $M+? The way record management operators are implemented is
that if you include any of the operators then the type becomes "managed" in the
same way other ref counted types are handled.
For classes this is different because there is a hierarchy which is now altered
but the compiler could still insert a hidden super class above it and use that
to store the extra data. Indeed this would mean that existing classes (like the
RTL) would not be eligible for reference counting unless it was compiled using
said directive.
For example the follow class:
{$RETAINED+}
type
TMyObject = class(TBaseClass)
end;
{$RETAINED-}
would become:
type
TMyObject_RefCounted = class abstract(TBaseClass)
strict private
refCount: LongInt;
end;
TMyObject = class(TMyObject_RefCounted)
end;
and now "TMyObject" is a managed type and Initialize/Finalize/AddRef/Copy will
be called. It occurs to me now though that the ref counting would be tied to
the type so if you cast the class to TObject and passed it around then ref
counting wouldn't happen. Not sure if that's a deal breaker or not but it could
easily cause hard to fix memory leaks just like normal classes. :)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 6, 2021, at 11:40 PM, Sven Barth wrote:
>
> There is no "finalization" section. It's really just an implicit try ...
> finally block that the compiler inserts. Look for "cs_implicit_exceptions"
> and "pi_needs_implicit_finally" if you want to learn more.
Does that mean if you disable implicit exceptions then ALL ref counted types
leak memory? I could swear there was some post-routine code did all the cleanup
stuff and called finalization* on different types. That's how record operators
worked I thought and so i thought a defer keyword could simply hook into that
system.
>> Either way looking at the programming language landscape the better way
>> forward seems to be some opt-in ARC for TObject but I don't know if the
>> compiler team is receptive to that (Sven made some attempt years ago but
>> abandoned it). it's kind of frustrating that we have ref counted types but
>> that isn't extended to classes. Hopefully that's something we can tackle one
>> of these days...
> The problem is that the whole class tree needs to support it for it to work
> correctly even if it's not the whole hierarchy that has as it enabled. That
> means at least one additional field inside TObject that a) controls that
> behavior and b) contains the reference count. This means that *all* class
> instances increase by a LongInt. This might not sound like much, but FPC also
> allows to work on smaller systems (and I don't mean the really small embedded
> ones as those don't have TObject enabled anyway) and there an additional
> LongInt for each instance might be critical.
That can never be an option to blow up TObject. I figured there could be
something like a $M+ switch that would compile a class with ref counting. Then
in the RTTI units we would simply have an entry for this new class type which
had initialize/finalize/addref etc... functions. I saw this for record
operators and dynamic arrays so I thought the system could be extended to
classes.
>
> If the reference count feature is optional (in addition to the above) then an
> open question is what would happen if such a reference counted instance is
> assigned to a non-reference counted one. This would need to take into account
> all ways such an instance or type can be used including TClass.
That doesn't sound like a problem to me but I haven't thought about it deeply.
If it was confusing there could be a new var section to denote ARC objects:
var
someClass: TMyObject;
retained
someClass: TMyObject;
begin
end;
{$RETAINED+}
type
TMyObject = class
private
someClass: TMyObject;
public retained
someClass: TMyObject;
otherClass: TObject; // this would give an error because class is not
compiled for ARC
end;
{$RETAINED-}
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 7, 2021, at 9:40 AM, Benito van der Zander via fpc-devel > wrote: > > the classic Delphi way was to use an interface for freeing. It only requires > one type and nothing blows up. > That's clever but even try..finally is less overhead. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] default property (was Defer keyword)
> On May 6, 2021, at 11:40 PM, Sven Barth wrote:
>
> In my opinion the better solution is to continue the road that Maciej started
> and to implement that "default field" concept together with operator
> hoistening so that records with management operators can be used as
> containers. This is essentially the way it's done in C++ as well (e.g. we use
> that extensively at work), but it needs some questions solved for the default
> field functionality. This way the functionality is definitely optional and
> can be controlled per-instance instead of per-type. What it wouldn't solve
> however would be the assignment problems ("wrapped" to non-"wrapped"
> instance) though that could be probably be more or less solved by only
> allowing an explicit conversion to the non-"wrapped" instance.
If you remember I already started this but it got WAY out of hand and I had to
basically abandon all my work on it because it was such a mess. The problem was
we opened the possibility of default properties being used on any type (could
be used for nullable types even) and this was in my opinion a mistake (at least
for now).
I'm not 100% behind the default implements property Sven proposed for traits
but it shares most of the functionality with the default property so maybe we
should figure out how to constrain the default property and work on that angle.
If I do continue on to the traits this code will be shared anyways.
What I learned is that hoisting the following members is very easy to implement:
- Methods
- Fields
- Properties
and these are much more complicated and had a massive code footprint on the
compiler:
- Operators
- Assignments
- Array indexing
- Implicit conversions (like if, while statements etc... these where needed for
nullable types but not for ARC)
From my experience I would say we ONLY allow Methods/Properties and MAYBE
fields and then ignore all the other stuff. Default properties can ONLY be a
class type now. There is already an := operator the record can implement and it
works with management operators already. This covers 90% of the use cases for
memory management and doesn't introduce all sorts of unpredictable stuff.
What about that?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 7, 2021, at 2:46 AM, Sven Barth via fpc-devel > wrote: > > I cannot speak for others, but I think 90% of potential use cases for ref > counting > would be covered like this in my code: objects that only live inside a > procedure. > > I think the same. There's also a function which returns dynamically allocated memory but doesn't intend for you to keep it around very long. Cocoa/Objective-C has a good system for this which is an "autorelease pool" and while it's not language construct but rather a runtime system it does rely on an "Any" type (called id in Objective-C) so that methods can be chained together like this: a := TArray.Create([1,2,3]).AutoRelease; We can't do this in Pascal because the AutoRelease functions return type is not compatible with the type of the caller. Could we add something like an "Any" return type to Pascal which is a type that is compatible with any class? This relies on an event loop that can capture this garbage and dispose of it but it goes a LONG way in helping with common memory management problems. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 7, 2021, at 3:08 AM, Michael Van Canneyt via fpc-devel > wrote: > > The introduction of generics and their abundant use in Delphi has noticably > slowed down the compiler and increased binary sizes. To my dismay, compile > times of 20 seconds up to 2 minutes have become not uncommon in Delphi. > Something almmost unthinkable in D7 days. Is it badly optimized or just overused? I don't have any way to compare but FPC seems pretty good with generics (Sven will know if there are any optimizations that could be made). Implicit function specialization will appear (at least at first) without any optimizations but I'll fix that later. > > If that can be avoided by use of a keyword for 90% of use cases, I think it > is worth thinking about it and not dismissing it offhand. I already raised the idea of an "auto" keyword some years ago already and it got rejected in favor of record operators. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 6, 2021, at 7:14 PM, Ryan Joseph wrote: > > This can be detected at compile and at least give a warning. "a" is a member > of TR and the element type of "a" is TR, then we're assigning TR to said > array. It's that simple I think. It also occurs to me that record management operators already allow these types of circular references. It's just par for the course with ref counting and something programmers need to be aware of. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 6, 2021, at 5:41 PM, Martin Frb via fpc-devel > wrote: > > You can already cause ref circles, no classes needed. > > type > TR = record > a: array of TR; > end; > > var > x: TR; > begin > SetLength(x.a,99); > x.a[0] := x; > end. This can be detected at compile and at least give a warning. "a" is a member of TR and the element type of "a" is TR, then we're assigning TR to said array. It's that simple I think. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel > wrote: > > There is a performance penalty when using them, which one reason why the > compiler sources don't use them. There's probably other reasons too. There > might be some speed-up potential where standard Exit calls are concerned, but > I'm not sure. I just did a search and I did indeed see a few try..finally blocks but not many. As I understand it there is a "finalization" section of each procedure which is used for ref counted objects so I assumed the statement was merely moved to that location but I guess there's some concerns over exceptions. Either way looking at the programming language landscape the better way forward seems to be some opt-in ARC for TObject but I don't know if the compiler team is receptive to that (Sven made some attempt years ago but abandoned it). it's kind of frustrating that we have ref counted types but that isn't extended to classes. Hopefully that's something we can tackle one of these days... Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 6, 2021, at 4:05 PM, Sven Barth via fpc-devel > wrote: > > Other than that, you're right and what Ryan is trying to do is definitely the > intended purpose of try ... finally. > Is there any runtime code involved with try..finally or does it just reorganize the code to run at the end of the block? My understanding of the defer keyword is that is was just a fancy way to move some code into a block which always gets run with a function exits. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 6, 2021, at 11:39 AM, J. Gareth Moreton via fpc-devel > wrote: > > In the example given: > > obj := TObject.Create; > defer objects.Free; > > What's wrong with Pascal's existing functionality? > > obj := TObject.Create; > try >... > finally >objects.Free; > end; > > If there's a concern about performance penalty, maybe the compiler can work > something out for simple finally blocks and just copy the code to any Exit > nodes found rather than calling the pseudo-procedure that a try...finally > block creates. I didn't know try..finally even worked like that. :) I thought it was just for exceptions but I see it captures exit also. The defer keyword is nicer on the eyes I would say because it don't require wrapping the entire function in a big block of code. So never mind then I guess. I'll start using try..finally and see how that works for me. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
> On May 6, 2021, at 10:44 AM, Marco van de Voort via fpc-devel > wrote: > > But those types have refcounting built-in and always active. Things like > defer don't, which makes that all objects gets refcounting overhead in case > somebody needs it for "defer". > > Contrary to Pascal both the language you reference have garbage collectors, > so their objects are already managed anyway, The idea of defer isn't necessarily about memory management but rather literally just deferring a statements execution until a predicable point in execution (end of a block or function). Those articles mentioned using them for file IO also so that you can be sure you're going to close the open file handle even if the function returns before. Memory management is just one obvious use case since we have this problem in Pascal often. I don't think this even affects ref counting of existing types because it all it does it move the statement to the end of the block. Maybe I'm not understanding your point though. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Defer keyword
Something which annoys me about Pascal is cleanup in which a function exits in multiple places but there is no formal way to free memory which may be used in the current scope. I say ultimately Pascal needs some opt-in automatic reference counting for TObject but the "defer" keyword would be helpful alternative to what we have now, which is nothing. The concept is very easy to understand and should be easy to implement by simply making a "defer" statement node which is added to a list and then called during function finalization like the other ref counted objects (dynamic array, interfaces etc). I've seen it appear in multiple languages already and it's a sound idea in my opinion. Is this something worth perusing for Pascal? https://www.hackingwithswift.com/example-code/language/how-to-delay-execution-of-code-using-the-defer-keyword https://www.geeksforgeeks.org/defer-keyword-in-golang/ procedure DoStuff; begin obj := TObject.Create; defer objects.Free; while true do begin // don't worry, obj will be freed safely if not obj.TrySomething then exit; end; end; Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
I found something sneaky I'd like to confirm before I decide what to do about it. 1) "T" in TAnyClass is specialized as Integer from the first parameter with TSomeClass (which is TAnyClass). 2) "U" is getting specialized as String by looking at the parameters in Compare() in which "U"(the second generic parameter) is String. This specializes the procedure correctly but it uses a very sneaky method which is very hard to discern. I feel like that if a generic parameter is already used (like T in specialize TCallback) then no further attempt should be made to look at the parameters and in the example below "U" would not be found and the function would fail to implicitly specialize. == type generic TAnyClass = class type TElem = U; end; type TSomeClass = specialize TAnyClass; type generic TCallback = function(a: T; b: U): integer; function Compare(a: TSomeClass.TElem; b: string): integer; begin result := 1; end; generic procedure DoThis(aClass: specialize TAnyClass; callback: specialize TCallback); begin callback(1, 'string'); end; begin DoThis(TSomeClass.Create, @Compare); end. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 22, 2021, at 9:52 AM, Ryan Joseph wrote: > >> Got this all integrated and put up the changes to >> https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another >> final review. :) > > The next thing to do now is to handle a memory leak. From the bug tracker: I just noticed a week has passed on this. Sven, do you have a reply to my previous message to clarify a little? I could make a guess at what you want but I'll probably just waste more time doing the wrong thing. :P Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Nested function closures
> On Apr 27, 2021, at 12:10 PM, Sven Barth via fpc-devel > wrote: > >> So as Sven wrote, you would be duplicating effort, needlessly, since it has >> to work always... If the compiler can decide that the heap interface is not >> needed and optimize it away: so much the better. But I doubt this will be >> possible. > > In nearly all cases the interface can't be optimized away. So as you showed it's not as bad as I thought, which is good, however my point was that in my scenario, which I argue is indeed very common, it could be implemented as a "nested anonymous function". My reasons: 1) Nested functions already exist and merely need an anonymous parser to be implemented (as I already did in that branch). 2) The interface is literally 100% useless as the object is never passed outside of the receiver (SortEntities). It will be created and destroyed with absolutely no value to the program whatsoever. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Nested function closures
Continued from our discussion at https://bugs.freepascal.org/view.php?id=24481. > if the compiler devs will allow me as soon as this is finished I want to > allow the existing nested functions functionality to work with anonymous > functions, so at the very least we don't need to generate the expensive > interface based object which often times is not even needed. At that point we > would need to make nested functions inline-able, which they are currently > not. But we're not there yet so lets not complicated anything by proposing > extensions to a feature that doesn't even exist yet. Sven replies: > > Getting rid of the interface only works in very narrow circumstances that are > so seldom in real world code that it is not worth the effort. I'm referring to my test I did a few years ago (https://github.com/graemeg/freepascal/compare/master...genericptr:anon_funcs) where I say we can use existing nested functions as a closure when passing is not required. As you can see I already implemented this quite easily but it is not related to the new forthcoming closures feature. I did in fact try to replace the interface with a record on the old closures branch but I ran into many problems I decided it wasn't the best route. Indeed there are many times where we don't want a heap allocated interface you can pass around but rather a simple inline function pointer like below. Consider this loop is run 60 times a second and allocating a useless class every time for no gain. This could easily be 1000*60=60,000 constructions and allocations of a class. for i := 0 to entities.Count - 1 do begin value := entities[i]; value.SortEntities(function(a, b: TEntity): integer begin // do stuff end ); end; So anyways what I propose is if a closure is never passed outside of scope (i.e. temporary) then use anonymous nested functions instead (like in my GitHub branch). If this is an acceptable approach I will personally do what is required to get it implemented along side the real closures. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] How does TFPGMap key compare work?
> On Apr 21, 2021, at 11:21 PM, Sven Barth wrote: > > You need to use named types, though for operators this is less useful, > because the compiler will implicitly convert different ShortString types to > find a suitable operator overload: Then the compiler must do this for all strings types by default right? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 16, 2021, at 11:35 AM, Ryan Joseph wrote: > > Got this all integrated and put up the changes to > https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another > final review. :) The next thing to do now is to handle a memory leak. From the bug tracker: > You essentially need to make sure the symbols become part of the > specialization that is picked in the end (cause you create the symbols in > make_param_list only once, but you might use them for multiple generic > overloads of which at most one will be picked). > What you might be able to do is the following (have not looked at it in > detail yet): > - those symbols you directly add to genericparams you ensure that their owner > is the specialization right away (after generate_specialization_phase1) > - those symbols you add to callerparams you'll probably have to bubble up to > htypechk and have that somehow add these syms to the final specialization if > it is picked and free them otherwise My response: > I looked at this again and it looks like there is just one place where we can > leak memory now and that's those lines from create_unamed_typesym. > > newtype:=ctypesym.create(def.typename,def); > newtype.owner:=def.owner; > > I set the owner of the new typesym to the target def but what does that even > do? I think you're saying I need to set the owner of that symbol to be a > procdef but I don't see how the helps the memory get freed. I would think > when the specialization is freed we could check some flag in the generic > params and if they are not owned then we free them then. And with that I'm stuck. :) I don't know how the symbols in the compiler are memory managed but I don't see setting their owner is helping them get freed. I've tried setting their owner to the procdef.owner being specialized but that does't do anything either. I guess I don't understand what adding them to "the final specialization" means so please clarify. My naive assumption would be to add them to a list in tspecializationcontext and free them when the content is freed because I don't think the symbols are used after the implicit specialization is finished and a proc def is produced, but I may be wrong about that. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
> On Apr 21, 2021, at 12:57 PM, Sven Barth via fpc-devel > wrote: > > You can only use global operators with objects. yes but not with *generic* objects. I find it very hard to understand why this is being blocked for objects. Without this there is no way to have *generic* record inheritance in Pascal. Is this seen as a problem or something that people would make a generic inheritable record type? Without this we have stupid things like having to reimplement TVec2, TVec3, TVec4 etc... because we can't simply inherit from the previous type. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] How does TFPGMap key compare work?
> On Apr 20, 2021, at 11:38 PM, Sven Barth wrote: > > All four string types provide built in > and < operators: On a side note how do you even make overloads (or type helpers for that matter) for short strings because String[10] isn't the same type as String[100]? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
> On Apr 18, 2021, at 1:37 AM, Sven Barth wrote: > > It has been decided back when operator overloads were introduced that they do > not replace existing, built in operators. This decision still stands. And we > see no reason to change that. This way a user can *rely* on what a certain > operator means based on the language reference guide. This is more important > than some convenience for certain use cases. > We still have some inconsistencies though because of the many other comparison operators which can already be overloaded but simply lack a class operator syntax and thus are not available to classes. // impossible overload operator = (left: TObject; right: TObject): boolean; // possible overload operator = (left: TObject; right: integer): boolean; // possible overload operator < (left: TObject; right: TObject): boolean; In fact other binary operators that don't have side effects (i.e. don't return the class type) are safe and could be allowed in generic classes also. // only way to overload + for TSomeClass operator + (left, right: TSomeClass): String; So it's really just about a number of inconsistencies with classes and that's why I wanted to fix it. Same with Objects as Benito has just pointed out again. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
> On Apr 21, 2021, at 7:44 AM, Benito van der Zander via fpc-devel > wrote: > > Hi, > > what about overloading operators for OBJECTs? > > They do not conflict with any default operators. > > I expected this to work, but it did not compile: > > > > type generic TXQHashset = object //(specialize > TXQBaseHashmap)... > class operator =(const a, b: TXQHashset): boolean; > end; yes I have patch to enable this via a mode switch (https://bugs.freepascal.org/view.php?id=36350) but it has been acknowledged and then ignored without explanation since 2019. This is still the only way we can use operator overloads for generic objects and objects are the only way to have record inheritance so it's a critical missing feature in my opinion. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
> On Apr 17, 2021, at 2:12 PM, Jonas Maebe via fpc-devel > wrote: > > The issue with allowing it for classes (generic or not) is that the the = > operator already has a meaning for them (pointer equality). I think in > general we don't allow overloading operators that have a built-in meaning. I see your point about there being a conflict for pointer quality but you can actually resolve it by casting to TObject, however as you note it could be confusing also. That's an interesting question I'd need to think about more but even so that is only the = operator with other pointer types. Here's the list of possible operators that don't have side effects to the caller and are worth considering and may be safe. class operator = (left: TSelf; right: TRight): boolean; class operator not (left: TSelf): boolean; class operator <> (left: TSelf; right: TRight): boolean; class operator < (left: TSelf; right: TRight): boolean; class operator > (left: TSelf; right: TRight): boolean; class operator <= (left: TSelf; right: TRight): boolean; class operator >= (left: TSelf; right: TRight): boolean; class operator >< (left: TSelf; right: TRight): boolean; class operator in (left: TSelf; right: TRight): boolean; Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Generic class comparison operators
Since I'm working on generics right now can we finally, at the very least, allow class operators for comparison operators? This is literally the only way for a generic class to override the = operator (along with some others) so there's no reason not to allow this. I understand the objection to :=, + etc.. where it returns a copy of a class instance and people could in theory do memory unsafe things, with comparison operators there is no possibility for this. I already made a patch for "advanced records" which is in limbo but It's trivial to adapt this for classes and put restrictions on the type of operator. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 16, 2021, at 2:44 AM, Sven Barth via fpc-devel > wrote: > > Yes, do that for now. > Got this all integrated and put up the changes to https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another final review. :) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 14, 2021, at 3:49 PM, Ryan Joseph wrote: > > It works but it thinks this array is array of const also so it's too strict I > believe. > > ['aaa', 'bbb']; About this, shouldn't we just be doing this? Any array constructor that has elements which are which are incompatible is "array of const"? from tarrayconstructornode.pass_typecheck: if eq=te_incompatible then diff:=true; Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 14, 2021, at 11:39 PM, Sven Barth wrote: > > Well, then I'll have to improve the check. But for now you can continue, > right? I can continue but if I include the check some tests will fail. Currently I've only made some changes in create_unamed_typesym and now this check to reject array of const. Everything else is done AKAIK unless we discover more bugs in the tests (which I've uploaded on the bug tracker). Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 14, 2021, at 2:33 PM, Sven Barth wrote: > > Had a bit of time to look at this. You can try the attached patch. You can > then check for both ado_IsConstructor and ado_IsArrayOfConst to detect such a > mixed array. It works but it thinks this array is array of const also so it's too strict I believe. ['aaa', 'bbb']; Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 11, 2021, at 3:33 PM, Sven Barth wrote: > > Looking at it, it could be that there is a bug in > tarrayconstructornode.pass_typecheck that hasn't really surfaced yet... I'll > have to look at that first, but I don't know when I'll have the time for that. sure I'll just leave it as is for now then. By the time the overloading happens it must know the array constructor is array of const but it should ideally be known by the time tarrayconstructornode.pass_typecheck is executed. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 10, 2021, at 9:47 AM, Ryan Joseph wrote:
>
> Just checked and pass_typecheck is called before overloading but
> ado_IsVariant is simply never set for that array. In tarraydef.GetTypeName
> you can see that "array of const" is associated with many flags so maybe we
> need to make a new flag which means "non-uniform elements"? I could probably
> easily build that into pass_typecheck for array constructors.
>
> ...
> if (ado_isarrayofconst in arrayoptions) or
> (ado_isConstructor in arrayoptions) then
> begin
> if (ado_isvariant in arrayoptions) or ((highrange=-1) and
> (lowrange=0)) then
> GetTypeName:='Array Of Const'
> else
> GetTypeName:='{Array Of Const/Constant Open} Array of
> '+elementdef.typename;
> end
>
Any word on what I should do about this? If those flags present are not
sufficient I'll add another flag but if that's not acceptable I'll simply have
to allow the user to specialize with these array types, even though they will
fail later one when the function is selected during overloading. Once I know
that I'll submit another patch including the other changes that were requested.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 10, 2021, at 9:18 AM, Ryan Joseph wrote:
>
> I checked before and here's what I got. Maybe pass_typecheck hasn't been
> called yet? If not I'll have to reproduce that code and determine how it
> knows the elements are not uniform. Thanks.
Just checked and pass_typecheck is called before overloading but ado_IsVariant
is simply never set for that array. In tarraydef.GetTypeName you can see that
"array of const" is associated with many flags so maybe we need to make a new
flag which means "non-uniform elements"? I could probably easily build that
into pass_typecheck for array constructors.
...
if (ado_isarrayofconst in arrayoptions) or
(ado_isConstructor in arrayoptions) then
begin
if (ado_isvariant in arrayoptions) or ((highrange=-1) and
(lowrange=0)) then
GetTypeName:='Array Of Const'
else
GetTypeName:='{Array Of Const/Constant Open} Array of
'+elementdef.typename;
end
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 10, 2021, at 6:54 AM, Sven Barth wrote:
>
> As an additional note: if you take a look at
> tarrayconstructornode.pass_typecheck you can see that the array type always
> has the ado_IsConstructor set and if it contains of incompatible types the
> ado_IsVariant is set as well. So if ado_IsVariant is *not* set, then you can
> rely on the elementdef of the arraydef.
I checked before and here's what I got. Maybe pass_typecheck hasn't been called
yet? If not I'll have to reproduce that code and determine how it knows the
elements are not uniform. Thanks.
elecount:4
typesym:{Array Of Const/Constant Open} Array of ShortInt
ado_IsConvertedPointer: FALSE
ado_IsDynamicArray: FALSE
ado_IsVariant: FALSE
ado_IsConstructor: TRUE
ado_IsArrayOfConst: FALSE
ado_IsConstString: FALSE
ado_IsBitPacked: FALSE
ado_IsVector: FALSE
ado_IsGeneric: FALSE
writeln('elecount:',tarraydef(caller_def).elecount);
writeln('typesym:',tarraydef(caller_def).typesym.realname);
writeln('ado_IsConvertedPointer: ',ado_IsConvertedPointer in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsDynamicArray: ',ado_IsDynamicArray in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsVariant: ',ado_IsVariant in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsConstructor: ',ado_IsConstructor in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsArrayOfConst: ',ado_IsArrayOfConst in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsConstString: ',ado_IsConstString in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsBitPacked: ',ado_IsBitPacked in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsVector: ',ado_IsVector in
tarraydef(caller_def).arrayoptions);
writeln('ado_IsGeneric: ',ado_IsGeneric in
tarraydef(caller_def).arrayoptions);
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel > wrote: > > You mean what you did for is_array_literal? A pure array constructor can be > found with is_array_constructor, though it might be better to use > is_open_array, cause someone might pass an open array parameter to a generic > function (those will be unnamed as well). Maybe the email didn't go through? How to identify this "array of const constructor" type. I want to reject these for implicit specialization but I can't identity them. DoThis([ 1, 'string', 'c', TObject.Create ]) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 9, 2021, at 3:08 PM, Sven Barth wrote: > > Possibly, yes... > > You could provide the various utility functions in a separate patch. Well I'm going to use them for this patch so they would all be batched together. Any idea about the "array of const" issue I raised in the other email? Once that's done I'll submit another very patch. Getting very close now unless I missed some test cases... Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
I just realized one more type introspection related issue. This currently will specialize as DoThis because the array constructor element type is "shortint" as is derived from the first element 1. This of course is not correct so I'd like to reject "array of const constructors" but I don't see how to know what when I get this type. I thought the tarraydef would have ado_IsArrayOfConst set but it does not, so how do I know the array constructor has multiple element types? generic procedure DoThis(a: array of T); begin end; begin DoThis([ 1, 'string', 'c', TObject.Create ]) end. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 8, 2021, at 11:37 PM, Sven Barth via fpc-devel
> wrote:
>
> That is because before the introduction of type helpers such functions
> weren't really needed. Other mechanisms caught such constants, but for both
> type helpers and these implicit specializations it's hard to do it another
> way.
Ok then I'll add a is_constant_string function for later use.
What about this function I'm using, should it be in defutils.pas also? I need
this so I can distinguish "unnamed array literals" like ['a','b','c'] from
short strings like 'abc'. They may be internally identical to arrays but
conceptionally they are different. Not sure about the naming so I chose "array
literal" but "anonymous array" would make sense also.
function is_array_literal(def:tdef): boolean;
begin
result := (def.typ=arraydef) and not is_constant_string(def);
end;
Btw, this block (from create_unamed_typesym) could be a useful helper function
in tstringdef, such as "get_default_system_type". I needed something similar to
get the char type for a string def (and added that method already) so this is
another logical extension to that.
case tstringdef(def).stringtype of
st_shortstring:
newtype:=search_system_type('SHORTSTRING');
{ st_longstring is currently not supported but
when it is this case will need to be supplied }
st_longstring:
internalerror(2021040801);
st_ansistring:
newtype:=search_system_type('ANSISTRING');
st_widestring:
newtype:=search_system_type('WIDESTRING');
st_unicodestring:
newtype:=search_system_type('UNICODESTRING');
end
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 8, 2021, at 3:53 PM, Sven Barth wrote: > > 1. you should not blindly assume that the def is a stringdef if it's not an > arraydef; at least use an internalerror to protect against problems here > 2. if it's really a stringdef and the return type is st_shortstring you > should indeed use SHORTSTRING (it's only constant strings which are a bit > more, let's say "dynamic") > 3. do an internalerror for st_longstring as those are currently not > implemented > 4. due to 2. you can move the case of newtype=nil into the if-clause with the > arraydef > > Otherwise, yes, the check for the string type is correct. I didn't know how constant strings we identified until just now so I can correct that. Can we make "(def.typ=arraydef) and (ado_isconststring in tarraydef(def).arrayoptions)" into a function in defutils.pas and call it is_constant_string? That would have been easily visible to me and lead me in the right direction from the start. I also had problems with array literals like [1,2,3] which there is no clear utility function for and prompted me to make is_array_literal() which is private right now (and probably not very correct in design). Moving that to a public space would be sensible also I think. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 7, 2021, at 1:56 PM, Ryan Joseph wrote:
>
> Ok, so with $H+ constant strings will be specialized as AnsiStrings. And
> there is another unicode string mode I should do a similar thing with? Also
> if you happen to know where I can get the state of $H+ that would be helpful
> otherwise I need to track it down in the debugger. :)
I think I got this part figured out (see function below). I'm going to upload
another patch and a bunch of unit tests on the bug tracker but I'm leaving my
latest ambiguous function call as-is until further notice. it's sneaky like it
is but it follows rules which you can manipulate using casting.
==
function create_unamed_typesym(def:tdef): tsym;
var
newtype: tsym;
begin
newtype:=nil;
if is_stringlike(def) then
begin
if (def.typ=arraydef) and (ado_isconststring in
tarraydef(def).arrayoptions) then
newtype:=nil
else
case tstringdef(def).stringtype of
st_shortstring:
newtype:=nil;
st_longstring,
st_ansistring:
newtype:=search_system_type('ANSISTRING');
st_widestring:
newtype:=search_system_type('WIDESTRING');
st_unicodestring:
newtype:=search_system_type('UNICODESTRING');
end;
{ not better string type was found so chose the default string
type }
if newtype=nil then
begin
if (cs_refcountedstrings in current_settings.localswitches)
then
begin
if m_default_unicodestring in
current_settings.modeswitches then
newtype:=search_system_type('UNICODESTRING')
else
newtype:=search_system_type('ANSISTRING');
end
else
newtype:=search_system_type('SHORTSTRING');
end;
end
else
begin
newtype:=ctypesym.create(def.typename,def);
newtype.owner:=def.owner;
end;
if newtype=nil then
internalerror(2021020904);
result:=newtype;
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
With the requested changes I believe some precedence rules have changed. These both should be "Can't determine which overloaded function to call" errors or the non-generic should take precedence because the functions are ambiguous (by appearance at least). Currently the compiler thinks DoThis is better than the non-generic and this may be because it was specialized as DoThis because the parameter of "1" is a ShortInt. What should the rule be here? = procedure DoThis(a: word; b: word); begin end; generic procedure DoThis(a:T; b: word); begin end; begin DoThis(1,1); // DoThis end. = generic procedure DoThis(a:T; b: word); begin end; generic procedure DoThis(a: word; b: T); begin end; begin DoThis(1,1); // Can't determine which overloaded function to call end. = Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 7, 2021, at 1:42 PM, Sven Barth via fpc-devel > wrote: > > Yes, we want to change that for two reasons: > - the constant string might be larger than 255 characters > - ShortString is worse for passing as a by-value parameter (which will be the > default after all) than AnsiString or UnicodeString as ShortString is > completely copied while Ansi-/UnicodeString are only references with > reference count adjustments Ok, so with $H+ constant strings will be specialized as AnsiStrings. And there is another unicode string mode I should do a similar thing with? Also if you happen to know where I can get the state of $H+ that would be helpful otherwise I need to track it down in the debugger. :) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 6, 2021, at 11:34 PM, Sven Barth wrote:
>
> In the second case the compiler will have the non-generic Test(String) due to
> the implicit operator as well as Test(LongInt) due to the implicit
> specialization. Here it will pick the generic one, because a call without a
> type conversion is considered better.
I finally get what you're saying and get the correct results now after moving
my check inside the if/then block. I didn't realize that the operator overload
was causing a type conversion that the overloading system knew about. So the
non-generic still wins unless the type conversion happened due to the operator
overload and then the generic wins.
Writeln(Test('Hello World')); // Test(String)
Writeln(Test(42)); // Test
Writeln(Test(String(42))); // Test(String)
As for $H+ do we really want string literals likes 'ABC' to change? I wouldn't
think so. Here's my string literal type symbol conversion in
create_unamed_typesym I'm using now:
case tstringdef(def).stringtype of
st_shortstring:
newtype:=search_system_type('SHORTSTRING');
st_longstring,
st_ansistring:
newtype:=search_system_type('ANSISTRING');
st_widestring:
newtype:=search_system_type('WIDESTRING');
st_unicodestring:
newtype:=search_system_type('UNICODESTRING');
end;
'Hello World' is parsed as st_shortstring so we use System.ShortString for
specialization. Given that I don't think I need to do anything with $H+.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 6, 2021, at 12:57 PM, Sven Barth wrote:
>
> In the example you posted below, I agree with you, but that is not what I
> said. Look at my example again:
Also could you please verify that $H+ isn't causing problems? The string
literal 'Hello World' is a short string but "String" is an AnsiString so that
may influence the results you're expecting. However even without the operator
I don't know how to delineate between the explicit cast vs the non-explicit
cast.
Writeln(Test('Hello World'));
Writeln(Test(String('Hello World')));
These both appear to be equal as far as is_better_candidate is concerned.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 6, 2021, at 12:57 PM, Sven Barth wrote:
>
> In this specific case the two functions also are *not* ambigous, because for
> the non-generic Test the parameter requires an implicit conversion, but the
> implicit specialization does not. For example if there would be a "Test(aArg:
> LongInt)" instead of the generic the compiler would pick that instead of the
> string one. So if you move the check for generic vs. non-generic to the end
> of is_better_candidate all the other rules to determine this will take
> precedence.
So the root of the problem is that we have no way to choose the generic
function via explicit casting? That makes sense and presumably I can use the
final result of is_better_candidate to determine this? In your example:
Writeln(Test('Hello World')); // is_better_candidate res = -1
Writeln(Test(42)); // is_better_candidate
res = 1
Writeln(Test(String(42))); // is_better_candidate res = -1
I'm struggling to see how the operator influenced the result. Res is -1 in both
cases so how do we know which Test we want to call?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Implicit function specialization precedence
Finally some movement is happening on implicit function specialization and I'm
almost finished now except some questions about precedence have been raised
again. Initially I thought we decided on non-generic functions taking
precedence in the case of *any* name collisions (the original thread
https://lists.freepascal.org/pipermail/fpc-pascal/2018-December/055225.html)
but Sven is saying now that this isn't the case (see the remarks on the bug
report https://bugs.freepascal.org/view.php?id=35261). I'm asking this here not
to go over Svens head but in hopes to get some answers quicker (it can take us
weeks sometimes to round trip even simple questions).
Currently what I implemented is that in the case below non-generic Test() will
take precedence even though Test could be specialized and indeed even comes
after. My questions:
1) What is required for Delphi compatibility? I never used Delphi and I thought
we decided this initially for Delphi compatibility. Of course we can make a
Delphi mode only option if we need to.
2) Svens final remarks on the bug tracker are "Right now your code will pick
the existing String overload even if specializing the generic might be the
better choice. If the user really wants the String one (or if the specializing
the generic does not work) the user can still force the String overload by
casting the parameter to a String.". I'm confused about this because
Test(String) and Test are both identical and thus I don't see what is
the "better choice".
Personally I feel like we should fallback to the non-generic function as a way
to resolve ambiguity but I can also see why Test should take precedence
simply because it comes after Test().
{$mode objfpc}{$H+}
{$modeswitch IMPLICITFUNCTIONSPECIALIZATION}
function Test(const aStr: String): LongInt;
begin
Result := 1;
end;
generic function Test(aT: T): LongInt;
begin
Result := 2;
end;
begin
Writeln(Test('Hello World'));
end.
And just to be clear even if the name is the same but parameters do not match
the generic function will be selected. For example below Test will be
specialized because Test() doesn't have a compatible signature.
function Test(const aStr: String): LongInt;
begin
Result := 1;
end;
generic function Test(aT: T; aInt: Integer): LongInt;
begin
Result := 2;
end;
begin
Writeln(Test('Hello World', 1));// prints "2"
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler message colour scheme
> On Nov 23, 2020, at 1:33 AM, Michael Van Canneyt via fpc-devel > wrote: > > I ran the compiler on linux through a ssh session: > > The colors display just fine, so I see no reason to disable on darwin except > that the termio unit is not found... If Florian wants to provide some explanation as to where the colors were added I'll enable them on mac and test them myself. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler message colour scheme
> On Nov 22, 2020, at 10:09 AM, J. Gareth Moreton via fpc-devel > wrote: > > Personally I'd write the function as something like "function > GenerateColorCode(codes: array of Byte): ansistring;", mostly in anticipation > of pure functions, because then the compiler can just replace the call with > the relevant string at compile time, but that's a long way off! That would great. Hopefully this gets finished some day. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler message colour scheme
> On Nov 22, 2020, at 9:29 AM, Florian Klämpfl via fpc-devel > wrote: > > Because I have no Mac so I couldn't test it. I see. It's this easy. const ANSI_FORE_BLACK = 30; ANSI_FORE_RED = 31; ANSI_FORE_GREEN = 32; ANSI_FORE_YELLOW = 33; ANSI_FORE_BLUE= 34; ANSI_FORE_MAGENTA = 35; ANSI_FORE_CYAN= 36; ANSI_FORE_WHITE = 37; ANSI_FORE_RESET = 39; ANSI_BACK_BLACK = 40; ANSI_BACK_RED = 41; ANSI_BACK_GREEN = 42; ANSI_BACK_YELLOW = 43; ANSI_BACK_BLUE= 44; ANSI_BACK_MAGENTA = 45; ANSI_BACK_CYAN= 46; ANSI_BACK_WHITE = 47; ANSI_BACK_RESET = 49; ANSI_STYLE_BOLD = 1; ANSI_STYLE_ITALIC = 3; ANSI_STYLE_UNDERLINE = 4; ANSI_STYLE_BLINK = 5; procedure PrintColor(codes: array of byte; str: ansistring); var attrs: string; code: byte; begin attrs := ''; for code in codes do begin if attrs <> '' then attrs += ';'; attrs += IntToStr(code); end; writeln(#&033,'[',attrs,'m',str,#&033,'[',0,'m'); end; // prints a blinking, bold red text on a white background PrintColor([ANSI_BACK_WHITE, ANSI_FORE_RED, ANSI_STYLE_BLINK, ANSI_STYLE_BOLD], 'Hello World'); Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler message colour scheme
> On Nov 22, 2020, at 8:57 AM, Jonas Maebe via fpc-devel > wrote: > > It's only enabled on Linux and Windows currently. Why is that? Mac has colors in the terminal also. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler message colour scheme
> On Nov 22, 2020, at 7:59 AM, J. Gareth Moreton via fpc-devel > wrote: > > Hi everyone, > > This might be me being a little bit picky, but I noticed the new colouring > scheme for words like "Warning" and "Error" in the output logs. Is there any > particular reason why "Warning" is in magenta? Normally the convention is > that it's yellow (and "Error" in red). Granted, it's purely cosmetic. > > Gareth aka. Kit What version of the trunk is this in and what's the flag to enable it? My trunk is maybe 30 days old and I don't see any way to get the colors. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Github hosting of FPC utilities and [stable] sources
> On Oct 13, 2020, at 7:06 AM, Michael Van Canneyt via fpc-devel > wrote: > > This is planned, we wait for 3.2.2 and then we move to git. will it go on GitHub also and replace the old mirror site we've been using or will you host it on the free pascal website? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal/discussion: Simple nested functions and 'outlining'
> On Oct 1, 2020, at 10:37 AM, J. Gareth Moreton via fpc-devel > wrote: > > In situations where a nested function has no parameters, is it feasible and > beneficial to programmatically merge it into the main procedure What do you mean by "merge"? Like inlining? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unknown compilerproc in r 46894
> On Sep 19, 2020, at 5:43 PM, Jonas Maebe via fpc-devel > wrote: > > It will work if you start your build with FPC 3.2.0 instead of 3.0.4. yes, that worked. thanks. 3.0.4 is officially not possible to use for bootstrapping I guess. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unknown compilerproc in r 46894
> On Sep 19, 2020, at 2:35 PM, Michael Van Canneyt > wrote: > > > It is a known issue, needs still to be fixed. > > Michael. A quick search suggests that https://bugs.freepascal.org/view.php?id=37221 is causing the problem. Sven applied my patch (array related) as well as this one which seems to be causing the problem. I'll wait until those guys resolve it. Thanks. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Unknown compilerproc in r 46894
I was just going to test the applied patch https://bugs.freepascal.org/view.php?id=36909 with revision 46894 and I got this error. Any ideas? /usr/local/lib/fpc/3.0.4/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/Users/ryanjoseph/Developer/fpc/rtl/units/x86_64-darwin -Fix86_64 -FEx86_64/bin/x86_64-darwin -FUx86_64/units/x86_64-darwin -dRELEASE -XR/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Fix86 pp.pas optdfa.pas(342,20) Fatal: Unknown compilerproc "fpc_dynarray_copy". Check if you use the correct run time library. Fatal: Compilation aborted make[5]: *** [ppcx64] Error 1 make[4]: *** [next] Error 2 make[3]: *** [ppc1] Error 2 make[2]: *** [cycle] Error 2 make[1]: *** [compiler_cycle] Error 2 make: *** [build-stamp.x86_64-darwin] Error 2 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature request/discussion - SetLengthNoInit
> On Sep 17, 2020, at 7:23 PM, Ryan Joseph wrote: > > Certainly. I think it depends on what the solution is. It's a known short > coming of the [] property and if the solution is as easy as allowing a var > param variant then maybe it's feasible. I'm remembering now I believe we did discuss this and it falls into the category of "not as expected" behavior because it appears like the [] property to write to record fields should work, because the language already gave you that idea from normal static/dynamic arrays. I may have even asked why it didn't work on the mail list and was reminded that it's a feature of the getter method which copies the record as it passes it back. That's not obvious to the programmer unless you really think about how the property is implemented under the hood by the compile. It would be more intuitive is the record was passed by reference, just like it is using normal [] operators on arrays. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature request/discussion - SetLengthNoInit
> On Sep 17, 2020, at 11:33 AM, J. Gareth Moreton via fpc-devel > wrote: > > I think the difficulty with getting things like this approved is that it > crosses into the realm of defining the language itself. I can't say I speak > on behalf of Florian or Jonas, but I sense they want to avoid feature bloat > that became a bit of an issue with Delphi. Certainly. I think it depends on what the solution is. It's a known short coming of the [] property and if the solution is as easy as allowing a var param variant then maybe it's feasible. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature request/discussion - SetLengthNoInit
Here's an example of the main problem that keeps us from using custom types to
replace dynamic arrays. We basically a need [] property modifier that treats
records the same way the dynamic array syntax does. GetValue could be a
procedure and use a var parameter and maybe even that would be enough. I don't
know what the solutions could be but if the compiler team actually agreed to
approve anything I would be happy to personally implement this myself.
{$mode objfpc}
{$modeswitch autoderef}
{$modeswitch advancedrecords}
program dyanmic_array;
type
TMyRec = record
x, y: byte;
end;
type
generic TArray = record
private type
PT = ^T;
private
data: array[0..1] of T;
function GetValue(index: integer): PT; inline;
procedure SetValue(index: integer; const value: PT); inline;
public
property Values[index: integer]: PT read GetValue write SetValue; default;
end;
TMyRecArray = specialize TArray;
function TArray.GetValue(index: integer): PT;
begin
result := @data[index];
end;
procedure TArray.SetValue(index: integer; const value: PT);
begin
data[index] := value^;
end;
var
r: TMyRec;
a: TMyRecArray;
begin
r.x := 1;
r.y := 2;
// WRONG: we need to use pointers to write to the array
a[0] := @r;
// CORRECT: we return pointers to the record so we can write to the
underlying data (autoderef must be enabled)
a[0].x := 100;
// CORRET: same as above but with member access and autoderef
writeln('x: ', a[0].x);
// WRONG: to copy the record out of the array we need to derefence the pointer
r := a[0]^;
writeln('r.x: ', r.x);
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature request/discussion - SetLengthNoInit
> On Sep 17, 2020, at 9:59 AM, J. Gareth Moreton via fpc-devel > wrote: > > type generic TMyArray = record > Data: ^T; > Length: PtrUInt; > end; > > The compiler will complain about T being an unresolved forward declaration. > Outside of specifying a second parameter for the pointer type (which would be > a little unfriendly for third-party users), there isn't really a way around > this. > To be clear all the features work but it's not as optimized as dynamic arrays and could be cumbersome with arrays of records. I think you're supposed to redeclare a pointer to T: type generic TMyArray = record type TP = ^T; public Data: TP; Length: PtrUInt; end; Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature request/discussion - SetLengthNoInit
> On Sep 16, 2020, at 9:10 PM, J. Gareth Moreton via fpc-devel > wrote: > > I figure I could design a dynamic array class, but it will very likely be > incompatible with SetLength no matter what I try to do, and unless I'm > mistaken, it won't have the benefit of automatically gaining an implicit > clean-up blocl if used as a local variable unless there's an automatic > reference counting feature that I'm not aware of. There are operators to do this now but they're only for records (https://wiki.freepascal.org/management_operators). You can easily make a reference counted type now but as I mentioned that are some drawbacks, some of which I'd like to correct if the compiler team allowed it. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature request/discussion - SetLengthNoInit
> On Sep 15, 2020, at 10:34 PM, J. Gareth Moreton via fpc-devel > wrote: > > I'm willing to settle with SetLength(array, len, ... len, NoInit: Boolean = > False), but of course it depends on the overall support for it, which isn't > looking too promising currently! > > I'd rather put the time into making custom list classes perform as well as dynamic arrays. I liked the idea that FPC has it's own native "array of" syntax but it's tied to the language and not flexible enough as we learn from time to time. Two biggest things I can think of right away: 1) We have management operators now for ref counting but the code is probably not as good as with dynamic arrays (the operator calls are not inlined I know). Also I was never able to get my patch for a Move operator added and I regard this as pretty important to avoid unnecessary copies. 2) I think for the [] operator to work with arrays of records you need to return pointers and enable the "autoderef" modeswitch to avoid the deref syntax (which is how dynamic arrays always work). Are there performance implications of this or do we get the same code as dynamic arrays? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Planning to experiment with FPC extentions
Boian just today I made a little patch for a bug in the compiler (https://bugs.freepascal.org/view.php?id=37650) and I recorded a short 8 min video showing the process. I'm admittedly pretty terrible at making videos but it may be useful to just see the basics. I'm using VSCode as the editor/debugger and I go into how that works with Pascal but obviously you could do this with Lazarus (I prefer the debugger in VSCode so I use that when I'm doing debugger heavy work). https://www.youtube.com/watch?v=eqUCPJYoEAo Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Planning to experiment with FPC extentions
I started by using lazbuild with one of the .lpi files included in the fpc sources (add debug information when building also). lazbuild /fpc/compiler/ppcx64.lpi Next thing to do is put a syntax error in a example program and build it using the compiler (/fpc/compiler/ppcx64 myprog.pas for example) and a debugger (I use VSCode on macOS now but Lazarus works). Step through the compiler line by line until you understand the basics of where you are. Eventually add more syntaxes to your example program and step around in the debugger to analyze how it works. That's basically all the information there is sadly. I thought of making a little screencast video of myself doing this but I'm not sure how useful that would be. > On Aug 26, 2020, at 7:57 AM, Boian Mitov via fpc-devel > wrote: > > Hello everyone, > > I have been planning for long time to try to add support for advanced RTTI to > FPC, but never had the chance to work on it. > I don’t even know how to start. Is there any information on how to setup for > recompiling the compiler sources and even where the sources and the project > files for the compiler are? > Can someone help me setup so I can start to study the code and see how I can > start working on it? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Advanced objects
> On Jul 24, 2020, at 6:07 AM, Kostas Michalopoulos via fpc-devel > wrote: > > There should be at least support for operators. I have a custom > dynamic array object type (i use objects instead of classes to avoid > unnecessary heap allocations) which would benefit a lot from such > support. I worked around not having management operators by putting > the data fields and core functionality inside a generic advanced > record which implements these operators and then using that inside the > object (so the values do get released automatically when the object > itself is released), but i also need support for at least the equality > operator as the dynamic array object has an IndexOf method that uses > that and it cannot be used with other dynamic arrays (so i cannot have > a dynamic array object which itself contains dynamic array objects > because i cannot provide a = operator for the dynamic array object > itself). I thought the core team was going to accept this patch because it doesn't really have any downsides. Classes should be able to support operator overloads also provided they don't return the class type itself (this was discussed at length with Sven) so at the very least =, >, < etc... should be supported. If the first patch ever gets accepted I would like to extend it to do that also. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Advanced objects
> On Jul 23, 2020, at 7:32 AM, Kostas Michalopoulos via fpc-devel > wrote: > > Hi, > > I'd also like to repeat that question since i was just trying to use > management operators for a generic object type (not class, not record) > that i want it to automatically initialize/shutdown itself (right now > i'm doing it manually but i'd prefer it if the compiler would do that > for me) and found that bug too. I never got management operators operators working for the mode switch anyways because I didn't know how to handle inheritance properly and this would cause extra scrutiny over the feature which was already in question. I have other patches which are not contested at all and are just sitting there for months so I think there's a very slim chance advanced objects (in any form) gets accepted at this point. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-announce] FPC 3.2.0 released!
> On Jul 4, 2020, at 8:10 PM, Marco van de Voort > wrote: > > But the syntax will be CARD(variable), and there are some minor > things wrong with it: (anyone?) I'm waiting on my patch for implicit function specialization to be reviewed since I did a redesign (as per Svens request). If there are any other code reviewers available I can finally get it cleaned up and submitted. specialize CARD(variable) is really verbose in ObjFPC mode so it would be nice to get this cleaned up. https://bugs.freepascal.org/view.php?id=35261 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pure function development
> On May 1, 2020, at 4:05 PM, J. Gareth Moreton > wrote: > > Okay, I'll give that a try - do I need to post the entire FPC repository > there with my changes, or just the diff/patch files? It shows the diffs for you. Fork the FPC project on GitHub (https://github.com/genericptr/freepascal) then clone it locally and make a new branch. Then you can navigate to the feature branch, for example on my GitHub I have a branch for "static array initialization": https://github.com/genericptr/freepascal/tree/static_array_init If you can find the little compare button you'll get a URL like this: https://github.com/graemeg/freepascal/compare/master...genericptr:static_array_init That shows the commits and changed files as a diff. It happens all automatically so all you have to do is push changes (in your git client or what ever you use). Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pure function development
> On May 1, 2020, at 6:46 AM, J. Gareth Moreton > wrote: > > Is there a good way to show you guys the work in progress and for you to make > more informed comments on the design along with any bugs and shortcomings? > I'm making progress with make a pure factorial function, but it's nowhere > near ready for general use. Do you have GitHub? if so put your work into a feature branch and we can browse your changes by looking at diffs. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature announcement: constant parameters for generics
I think constants in generics may be the only way to create dynamically sized types at compile time (via static arrays). That seems like a really narrow usage but it opens a lot of doors most of us have probably never thought about. I suspect in time more good usages will be discovered. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature announcement: constant parameters for generics
> On Apr 26, 2020, at 4:02 PM, Michael Van Canneyt > wrote: > > Fixed-length arrays are the only practical use I can think of. I think you're right. Here's what I'll say next time: They're for composing types of dynamic size at compile time. :) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature announcement: constant parameters for generics
> On Apr 26, 2020, at 2:38 PM, Michael Van Canneyt
> wrote:
>
> As the original author, can you say something about the intended use of this
> feature ?
It was meant for a pretty narrow use of array types. If I knew how much work it
would be to implement I probably would have not done it. :P I personally wanted
it for static array lists that had methods like Add/Delete.
Here's an example of something I came across in a C++ project for decoding some
data files old DOS games.
==
{$mode objfpc}
program Block;
type
generic TBlock = record
bits: array[0..(Alpha + Depth) - 1] of T;
end;
type
TBlock32 = specialize TBlock;
{ ... other block types ... }
begin
end.
Here's an example from the bug tracker by another user (Akira) that helped with
testing. More arrays you'll note.
==
program ConstMatrixExampleObjFPC;
{$mode ObjFPC}
{$modeswitch AdvancedRecords}
type
String3 = String[3];
generic TRawMatrix = array[0..N-1] of array[0..N-1] of
T;
generic TMatrix = record
private type
ArrayType = specialize TRawMatrix;
private
Data: ArrayType;
public
class operator :=(constref Arr: ArrayType): TMatrix; inline;
procedure Display;
end;
class operator TMatrix.:=(constref Arr: ArrayType): TMatrix;
begin
Result.Data := Arr;
end;
procedure TMatrix.Display;
var I, J: SizeInt;
begin
WriteLn('[');
for I := 0 to N - 1 do begin
Write(' [');
for J := 0 to N - 2 do
Write(Data[I, J], ', ');
Write(Data[I, N - 1]);
Writeln('] ');
end;
Write(']');
end;
const RawMat: specialize TRawMatrix = (
('AAA', 'BBB', 'CCC', 'DDD'),
('EEE', 'FFF', 'GGG', 'HHH'),
('III', 'JJJ', 'KKK', 'LLL'),
('MMM', 'NNN', 'OOO', 'PPP')
);
var Mat: specialize TMatrix;
begin
Mat := RawMat;
Mat.Display();
end.
And another example from him that gets pretty clever. ;)
==
program Example;
// using Delphi-mode here as a matter of preference...
{$mode Delphi}
type
Meters = record
public const
ToKilometers = Value / 1000;
Unconverted = Value;
ToCentimeters = Value * 100;
ToMillimeters = Value * 1000;
ToFeet = Value * 3.28084;
end;
procedure Test;
type
TenMeters = Meters<10>;
const
KILOMETER_VALUE = TenMeters.ToKilometers;
UNCONVERTED_VALUE = TenMeters.Unconverted;
CENTIMETER_VALUE = TenMeters.ToCentimeters;
MILLIMETER_VALUE = TenMeters.ToMillimeters;
FOOT_VALUE = TenMeters.ToFeet;
begin
WriteLn(KILOMETER_VALUE : 0 : 4);
WriteLn(UNCONVERTED_VALUE);
WriteLn(CENTIMETER_VALUE);
WriteLn(MILLIMETER_VALUE);
WriteLn(FOOT_VALUE : 0 : 4);
end;
begin
Test();
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature announcement: constant parameters for generics
> On Apr 26, 2020, at 5:13 AM, Sven Barth via fpc-devel > wrote: > > The Free Pascal team is happy to announce the addition of a new language > feature: constant parameters for generics. Excellent! Thanks for getting this merged. It was a long battle but it's finally over. ;) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Advanced objects
Checking in on old bug report for "advanced objects" which was marked as acknowledged on the tracker. Was there ever any discussion of this and possibility of it being applied? I don't think it caused any controversy so I was hoping to get to use it some time soon. :) https://bugs.freepascal.org/view.php?id=36350 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
