I mentioned this as an aside a while ago but I don’t remember getting a response so I’d like to formally reintroduce the issue.

Should I file a bug report for this or is it expected behavior? Personally I’d really like to get implicit array overloads working properly.

program test;
type
	TMyClass = class
	end;
operator + (left: TMyClass; right: array of integer): TMyClass; overload;
var
	i: integer;
begin
	for i in right do
		writeln('add ', i);
	result := left;
end;
var
	c: TMyClass;
begin
	c += [1, 2, 3]; // ERROR: Operator is not overloaded: "TMyClass" + "Set Of Byte"
end.

Regards,
Ryan Joseph

I'd say it's a bug in the sense that the compiler assumes something starting with "[" and ending with "]" can only possibly be a set in that context.

Also, one other thing: you should *really* be specifying the right-hand-side array parameter as "const" there. If you don't, it will be copied in its entirety instead of being passed by reference. Basically just always pass everything as "const" (or "constref" if it's specifically a record) unless you literally can't.

Hello,
 
you can define type:
 
TIntArray = array of Integer;
 
operator + (left: TMyClass; right: TIntArray): TMyClass; overload;  
and with retyping it works:
 
c := c + TIntArray([1, 2, 3]);
 
V.
 
 
______________________________________________________________

I'd say it's a bug in the sense that the compiler assumes something starting with "[" and ending with "]" can only possibly be a set in that context. On Sun, Jul 22, 2018 at 12:10 PM, Ryan Joseph < > wrote: I mentioned this as an aside a while ago but I don’t remember getting a response so I’d like to formally reintroduce the issue.

Why wouldn't you just use the TIntegerArray type that's implicitly declared in the "Objpas" unit by default, if you were going to do that? Doesn't address the underlying issue anyways.

On Jul 22, 2018, at 6:22 PM, Ben Grasset wrote: Also, one other thing: you should really be specifying the right-hand-side array parameter as "const" there. If you don't, it will be copied in its entirety instead of being passed by reference. Basically just always pass everything as "const" (or "constref" if it's specifically a record) unless you literally can’t.

Yeah sounds like a bug but I’ll wait for one the compile guys to verify that.

I belive I was told that const doesn’t actually perform any optimizations but constref does (for structs yes). I hope that’s right because I don’t want to feel an urge to type “const” every time I write a function. Honestly I don’t think I’ve ever used const but just started using constref last year when I learned about it for the first time (good feature when ever it was added).

Regards,
Ryan Joseph

Ryan Joseph schrieb am So., 22. Juli 2018,
18:11:

Yes, it's a bug, so please report it.

Regards,
Sven

On Jul 23, 2018, at 12:00 AM, Sven Barth via fpc-pascal wrote: Yes, it's a bug, so please report it.

Thanks, reported. The severity is “minor” which I guess is correct.

https://bugs.freepascal.org/view.php?id=34021

Regards,
Ryan Joseph

Ryan Joseph schrieb am Mo., 23. Juli 2018,
17:35:

"Minor" is the default severity. We have made the value not editable by users, cause they'd more often than not consider their bugs as more severe than really severe bugs.

Regards,
Sven

On Mon, Jul 23, 2018 at 1:49 PM, Sven Barth via fpc-pascal <

Someone posted a working patch for this on the bugtracker report Ryan made, just to let you know.

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

On Jul 28, 2018, at 8:38 AM, John Doe wrote: Someone posted a working patch for this on the bugtracker report Ryan made, just to let you know.

Thanks, what do we do now? The patch is sitting there but how does it get applied?

https://bugs.freepascal.org/view.php?id=34021

Regards,
Ryan Joseph

If you don't have an SVN patch utility handy you could probably just look at it and apply it to your sources yourself. The final version looks like it's just two lines changed in a single file.

By looks like I meant, "is", not sure why I wrote that. (I'm Akira1364, by the way.)

On Jul 30, 2018, at 4:11 PM, Ben Grasset wrote: If you don't have an SVN patch utility handy you could probably just look at it and apply it to your sources yourself. The final version looks like it's just two lines changed in a single file.

Thanks for fixing that Ben. I don’t have SVN access (I did some time long ago when I was doing the Objective-C stuff but I forgot it) so there’s not much I can do. Does the compiler team know about the patch and will they apply it? I saw the bug report was closed so I didn’t want them to not see it.

Regards,
Ryan Joseph

It's still open by my view, with "new" status:

https://bugs.freepascal.org/view.php?id=34021

Working, yes, complete, no.

Nevertheless I fixed the problem in r39554.

Regards,
Sven

On Sat, Aug 4, 2018 at 10:38 AM, Sven Barth via fpc-pascal <

Would be interested to know what I missed with the patch for future reference (and for better understanding of the compiler codebase.)

Your patch would not have worked with any other types that could be used for an operator overload with an array. Also there would have been troubles with overloads with sets. Just look at the changes I did and compare to those you did.

Regards,
Sven

On Aug 4, 2018, at 8:38 AM, Sven Barth via fpc-pascal wrote: Nevertheless I fixed the problem in r39554.

Thanks Sven.

Regards,
Ryan Joseph