Re: [fpc-pascal] Syntax changes suggestions

On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > Because a feature might change the language in a way that's not in the > spirit of the language. Look at how Delphi implemented attributes: they're > declared in front of the types, fields, para

Re: [fpc-pascal] Syntax changes suggestions

Isn't Delphi compatibility a major ongoing goal of both FPC and Lazarus, though? On Fri, Jul 20, 2018 at 10:01 AM, R0b0t1 wrote: > On Fri, Jul 20, 2018 at 12:20 AM, Sven Barth via fpc-pascal > wrote: > > Am 20.07.2018 um 00:53 schrieb Ben Grasset: > >> > >> If a feature works as intended and is

[fpc-pascal] Operator overload bug

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

Re: [fpc-pascal] Operator overload bug

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 l

Re: [fpc-pascal] Operator overload bug

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

Re: [fpc-pascal] Operator overload bug

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.     __ Od: Ben Grasset Komu: FPC-Pasc

Re: [fpc-pascal] Operator overload bug

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 Sun, Jul 22, 2018 at 9:10 PM, Vojtěch Čihák wrote: > Hello, > > > > you can define type: > > > > TIntArray =

Re: [fpc-pascal] Operator overload bug

> 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

Re: [fpc-pascal] Operator overload bug

Ryan Joseph schrieb am So., 22. Juli 2018, 18:11: > 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 ar

Re: [fpc-pascal] Syntax changes suggestions

On 7/21/2018 1:43 PM, Ben Grasset wrote: Shouldn't the attribute tags just be put wherever it's easiest for the compiler to deal with them? That would be bending the language to fit the implementation, when it should be the other way around. I think the vast majority of people care far

Re: [fpc-pascal] Syntax changes suggestions

On Sat, 21 Jul 2018, Ben Grasset wrote: On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: Because a feature might change the language in a way that's not in the spirit of the language. Look at how Delphi implemented attributes: they're decla

Re: [fpc-pascal] Syntax changes suggestions

Am 21.07.2018 um 22:43 schrieb Ben Grasset: On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal > wrote: Because a feature might change the language in a way that's not in the spirit of the language. Look at how Delphi implemented attri

Re: [fpc-pascal] Syntax changes suggestions

El 21/07/18 a las 22:43, Ben Grasset escribió: Shouldn't the attribute tags just be put wherever it's easiest for the compiler to deal with them? No, of course the shouldn't. They should be put put where it is easier for programmer, or more readable, or coherence, or common sense, or other re