Is this a bug? It should resolve to:

d.setter(d.getter + 10)

but it doesn’t seem to be working.

========================================

{$mode objfpc}
{$modeswitch advancedrecords}
program test;
type
  TData = record
    x: integer;
  end;
type
  TVec2Helper = record helper for TData
    function Getter: integer;
    procedure Setter(newValue: integer);
    property Get: integer read Getter write Setter;
  end;
function TVec2Helper.Getter: integer;
begin
  result := x;
end;
procedure TVec2Helper.Setter(newValue: integer);
begin
  x := newValue;
end;
var
  d: TData;
begin
  d.get += 10;	// ERROR: Variable identifier expected
end.

Regards,
Ryan Joseph

PM Ryan Joseph wrote

begin d.get += 10; // ERROR: Variable identifier expected end.

AFAIK you cannot do that to a property (not even if it maps to a field). Delphi does not allow it either IIRC.

This is forbidden by design.

Regards,
Sven

On Aug 11, 2019, at 11:41 AM, Sven Barth via fpc-pascal wrote: This is forbidden by design.

Why? It makes sense it should resolve to: d.setter(d.getter + 10) but maybe there’s a problem?

Regards,
Ryan Joseph

For me it seems that you can solve the issue easily with existing technologies.
Moreover the code will be better to read and to handle in my opinion. Otherwise your code will be likewise C code with much information in the smallest place. That is not good to handle in my opinion. I have some experience with C code. It is not my preferred language.

d.x += 10; // makes even more sense

On Aug 11, 2019, at 3:59 PM, Alexander Grotewohl wrote: d.x += 10; // makes even more sense

Ok, you win. Here’s more or less the full snippet.

type
  TRectHelper = record helper for TVec4
    private
      procedure SetAxisX(newValue: TScalar); inline;
    public
      function MinX: TScalar; inline;
      function MinX: TScalar; inline;
      property AxisX: TScalar read MinX write SetAxisX;
  end;
function TRectHelper.MinX: TScalar;
begin
  result := v[0];
end;
function TRectHelper.MaxX: TScalar;
begin
  result := v[2];
end;
procedure TRectHelper.SetAxisX(newValue: TScalar);
begin
  v[0] += newValue;
  v[2] += newValue;
end;

==============================

rect.axisX += 10 is a compound statement. See it makes perfect sense. :) I still don’t understand why the compiler and Delphi apparently thinks this is such a crazy idea. It's just normal stuff imo.

Regards,
Ryan Joseph

This question pops up from time to time since 15 years if not more.

Some operators need actual variable addresses. A property does not have an address. It also becomes difficult if you have interfaces & classes or other overloaded things.

The compiler people can give a more detailed answer.

Michael.

Michael Van Canneyt wrote

This question pops up from time to time since 15 years if not more.

Fun fact: questions asking why this doesn't work have a higher Google ranking than the manual for "COPERATORS" ;-)

@Ryan: as with all things FPC, ignore the manual, read the parser: <https://github.com/graemeg/freepascal/blob/4e6c609/compiler/pexpr.pas#L221>

Turns out c-operators do not actually translate to their long form but instead have special, duplicated handling. Because of course they do.

Martok schrieb am Mo., 12. Aug. 2019, 10:18:

The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so except for using a temp to avoid duplicate calculation of "a" in how far is this not the long form?

Regards,
Sven

Sven Barth wrote

The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so except for using a temp to avoid duplicate calculation of "a" in how far is this not the long form?

No, I meant it doesn't re-parse as its long form, which is why it has some limitations. In this case for example handle_propertysym does not know it is actually seeing an assignment.

I don't think the compiler can do this? Macros are expanded on the scanner level, token stream injection is not a thing in FPC, AFAICS?

Martok schrieb am Di., 13. Aug. 2019, 14:44:

It could be done, but property support for the C operators is not *desired*. See the entry of the function you posted: properties are explicitly rejected.

In general the C operators are not desired. They where added way in the past in a weak moment and I don't think they'd be added today if FPC wouldn't have them already.

Regards,
Sven

If the compiler would do that, the behaviour could change from what you would expect from glancing over the code, because the left-hand side would be evaluated twice instead of once.

Jonas

On Aug 13, 2019, at 11:09 AM, Sven Barth via fpc-pascal wrote: In general the C operators are not desired. They where added way in the past in a weak moment and I don't think they'd be added today if FPC wouldn't have them already.

Seriously? why is i := i + 1 better than i += 1 ? just more typing for such a simple operation. All languages I use have adopted this syntax and for good reason.

Regards,
Ryan Joseph

Ryan Joseph wrote

Seriously? why is i := i + 1 better than i += 1 ? just more typing for such a simple operation. All languages I use have adopted this syntax and for good reason.

good reason?? because someone is too lazy to type 4 more characters? yes, i'm counting the readability spaces which could easily be left out...

/me tightens belt on asbestos britches...

On Aug 14, 2019, at 11:41 AM, wrote: good reason?? because someone is too lazy to type 4 more characters? yes, i'm counting the readability spaces which could easily be left out...

yes, that’s exactly why. Programers got sick of wasting time typing redundant characters so they attacked the problem at the root. It’s so intuitive that basically all languages have adopted the syntax. I’m not saying you should but it’s going to hurt Pascal if we ignore these kinds of trends.

Regards,
Ryan Joseph

Op 14-08-19 om 17:45 schreef Ryan Joseph:

Roflol... yeah... people do not use Pascal because they have to type:
i := i + 1;

Sure.

Thanks for the laugh, though. But completely off-topic. I shouldn't have responded.

Regards,

Joost.

I’m once again shocked that anyone would be against such syntaxes as += so maybe the compiler needs to put them behind a modeswitch. Given what Sven said I’m surprised they didn’t do this from the start. Even “out” is behind a mode switch after all.

Regards,
Ryan Joseph

I am so sick of typing all the characters...

No, your eyes get sick if you have to read C code.

If you had a real problem where there is no solution at the moment I could understand you. But there is no problem, and no one is preventing you from writing good and readable code.

It’s so intuitive that basically all languages have adopted the syntax.

That is not true.

I’m not saying you should but it’s going to hurt Pascal if we ignore these kinds of trends.

Also not true.

All languages I use have them: Pascal, C, PHP, C#, Swift, Python, JavaScript. These are some of the most popular languages in the world right now. You’re fighting a losing battle sir.

Regards,
Ryan Joseph

I don't see what the issue is ?

You do have += and the like. They exist, since about as long as I can remember.

You just cannot use it on properties.

Properties have some other restrictions as well:

* You also cannot Use Inc() on integer properties,
* or use Include()/Exclude() on set properties.
* You also cannot do SomeRecordProp.X:=Y;
* or pass them to functions that require var arguments.

And I'm probably forgetting some other limitations.

The += is just another one in the list of limitations of properties.

Basically any operation that requires an address is not allowed. That += is using an address is an implementation detail of the compiler. Same as Inc() or In/Exclude(). I don't know the exact reason for this limitation, but it's bound to be a good one, otherwise it would have been lifted a long time ago...

And if someone doesn't like these limitations of properties, (s)he can use fields. No-one abolished those, after all.

Michael.

I’m just responding to the fact Sven he regretted added them for some reason (and others now I’m learning). I just can’t understand that.

As per the original message I seriously thought it was a bug but there are technical implications apparently. I was going to fix it but there’s no interest in doing that so I’m just going to work around it for now. No problem.

Regards,
Ryan Joseph

CEST Michael Van Canneyt wrote

On Wed, 14 Aug 2019, Ryan Joseph wrote: >> On Aug 14, 2019, at 12:04 PM, Rainer Stratmann <

Didn't you know that Ryan?

Ryan Joseph schrieb am Mi., 14. Aug. 2019, 18:04:

They already are, but not a modeswitch, but a directive: {$COperators On/Off}. Probably from a time before modeswitches were introduced. It's even per default off. The default fpc.cfg however enables them...

And "out" is behind a modeswitch because modes like TP and ISO don't know that concept.

Regards,
Sven

Michael Van Canneyt schrieb am Mi., 14. Aug. 2019, 18:24:

The restriction regarding taking an address was only started to be enforced in 2.4.0 (see
https://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields) and further extended to records in 2.6.0 (see
https://wiki.freepascal.org/User_Changes_2.6.0#Taking_the_address_of_fields_of_record_properties ). The idea is to have properties backed by a field and backed by methods behave identically.

Regards,
Sven

On Aug 14, 2019, at 12:33 PM, Rainer Stratmann wrote: Didn't you know that Ryan?

Yes, of course, I use them all the time and it’s why I was defending them from their critics (which I still find hard to believe even exist). Anyways, they exist and can be disabled using the directive Sven mentioned. Everyone wins. :)

Regards,
Ryan Joseph

I have only used  += once;  I normally would not use I:=I+1; or I+=1;   I would use Inc(I);

FPC does not compile I+=1; by default, you have to go into compiler options and turn on C-Like operators.. I'm sure Lazarus turns this on by default, but it's not the normal default for just FPC. I know it is not the default because I just installed FPC and if would not compile the exactly 1 instance I used += until I went in and turn on C-Like operators.

As far as typing code goes,  I find all the begin's and end's to take more effort than anything else...  but I can type a block of
   Begin
   End
Else
   Begin
   End;
Super fast now anyway... and I find that I defiantly PREFER to make the effort because the code is much more readable than things like python that don't use anything but indentation or C that uses the {} braces..   I find it so much easier to follow after the fact having begin and end than trying to follow a huge chain of braces which blend in way too easily with parenthesis ().  Also most coding has more to do with cutting and pasting than actually typing things out anyway.  Readability after the fact is simply WAY more important than how many keyboard keys you need to hit to get the code on the screen.

James

On Aug 14, 2019, at 2:53 PM, James Richters wrote: I have only used += once; I normally would not use I:=I+1; or I+=1; I would use Inc(I);

Here’s an example of why we like c-style operators, i.e. it reduces redundancy of the variable name. It’s no surprise that programmesr figured out "viewTransform := viewTransform  *” could be compressed and still have the same meaning.
  viewTransform := TMat4.Identity;
  viewTransform *= TMat4.Translate(x, y, 1);
  viewTransform *= TMat4.Scale(scale, scale, 1);
	or
  viewTransform := TMat4.Identity;
  viewTransform := viewTransform  * TMat4.Translate(x, y, 1);
  viewTransform := viewTransform  * TMat4.Scale(scale, scale, 1);

Regards,
Ryan Joseph

They already are, but not a modeswitch, but a directive: {$COperators On/Off}. Probably from a time before modeswitches were introduced. It's even per default off. The default fpc.cfg however enables them...

No, the default is for ”C-Like operators” to be disabled in FPC. I just deleted fp.cfg and ran the text IDE and “Allow LABEL and GOTO” and “Allow inline” are the only two compiler options that are on by default with FPC… note this it not the Lazarus version of FPC, which has been modified, in fact the Lazarus version does not even have the text IDE included with it. If anything perhaps it is a bug of Lazarus to turn it on by default when FPC by itself has it off by default.

James

I find
  viewTransform := TMat4.Identity;
  viewTransform := viewTransform  * TMat4.Translate(x, y, 1);
  viewTransform := viewTransform  * TMat4.Scale(scale, scale, 1);

much more readable.

But I would just do:
  viewTransform := TMat4.Identity  * TMat4.Translate(x, y, 1) * TMat4.Scale(scale, scale, 1);

why bother storing the intermediate results at all?

Putting the operator before the = makes you have to go back and look to see what the operator is, where having the code in Result := Term * Term;  format is more readable because you read it left to right and the operators are in the correct order they are actually used.   I admit I am probably biased by looking at code without += for 35 years, but I still find it more readable.   I completely understand += -= *= and /= I just don't care for it from a readability point of view.. and figuring our what some code is doing 2 years from now is way more important than getting it to work right now... it's when you go back later you want it to be as readable as possible.  I guess I just prefer  Variable := Formula;  syntax and the clarity of it.

James

then by having both we all win. I never said we shouldn’t both, I’m just reacting to the idea that FPC almost didn’t include them because they "aren’t desirable".

Maybe that was a bad example but I still like to break up lines. For anyone that knows, does the compiler have any fancy optimizations to not store the intermediate results?

Regards,
Ryan Joseph

PM James Richters wrote

No, the default is for ”C-Like operators” to be disabled in FPC.

No, Sven is right.
This is in the default fpc.cfg
# Allow goto, inline, C-operators, C-vars
-Sgic

Of course if you delete that file, then all these are off.

Am 14.08.2019 um 17:41 schrieb

4 characters in your case, but if you have for example:

CALL_LVL [ LOCAL_CALL ] := CALL_LVL [ LOCAL_CALL ] + 1 ;

and you write instead:

CALL_LVL [ LOCAL_CALL ] += 1;

it's more than 4 chars, and it's easier, when it comes to changes, and and and ...

This is only a simple example; consider arrays with more indexes and record components and pointer references ...

BTW: the two statements are not equivalent, if the index expression contains for example a function call with side effects :-)

PL/1 is another language which has been enhanced to support this notation some years ago.

Kind regards

Bernd

We're talking apples and oranges here.. sorry my mistake. I was referring to the defaults in the Text IDE, fp.cfg, not fpc.cfg. If you delete fp.cfg or run the Text IDE (fp.exe) from a directory you never ran it in before, it creates new fp.cfg, and fp.ini and the default for those new files it creates is to have nothing on except "Allow LABEL and GOTO" and "Allow inline". All other Syntax Switches are turned off including "C-like operators" by default when the text IDE creates a new fp.cfg and fp.ini from scratch.

James

Bernd Oppolzer wrote

4 characters in your case, but if you have for example: CALL_LVL [ LOCAL_CALL ] := CALL_LVL [ LOCAL_CALL ] + 1 ;

  inc(CALL_LVL [ LOCAL_CALL ],1)

"inc(,)"  vs "+="
6 vs 2 chars

4 more.

Yes, "inc" does not work for properties. But neither does +=.

and you write instead: CALL_LVL [ LOCAL_CALL ] += 1;

Le 14/08/2019 à 23:18, Martin a écrit :

inc(CALL_LVL [ LOCAL_CALL ],1) Yes, "inc" does not work for properties. But neither does +=.

I agree and in the case of a property I think it would be cleaner to code an Inc method directly in the class, or eventually in a class helper, to write something like:

CALL_LVL [ LOCAL_CALL ].Inc(1)

In case of property, it's likely that you'll even be able to optimize the code, trimming some lines of the getter and the setter in you Inc method.

This said, I like to use += when I code in C++ for Arduino

I also think to the worse case, in Java, when you need to type something like a.SetX( a.GetX()+1) ...
And to Python, where in the code of the methods I need to prefix all accesses to methods and attributes of the object with "self." I have some code self. self. self. everywhere ...
Variant in Javascript: this. this. this.
Variant in PHP: $this. $this. $this.

Yes, I keep my FreePascal   ;-)

I agree, I hate the self. And this. I really don't even understand them... I'll keep Freepascal too, which I've been able to do more with than I ever imagined possible.

James

I also think to the worse case, in Java, when you need to type something like a.SetX( a.GetX()+1) ... And to Python, where in the code of the methods I need to prefix all accesses to methods and attributes of the object with "self." I have some code self. self. self. everywhere ... Variant in Javascript: this. this. this. Variant in PHP: $this. $this. $this.

Please note that this won't work if CALL_LVL is a property and the returned type is a record is the returned value will be a temporary variable, thus you'd increase the value of the temp, but not of the one stored in the class.

Regards,
Sven

Even in your sentences you put (too) much in a small place. I can hardly understand what you mean.
May by I am not so good in English language.