Const record parameters by default

[Ryan J]

(online https://godbolt.org/z/477r9hEEv)

So here you can see that everything is passed by value but purity is focused on the global state.
This gives a guarantee that the parameter will not be modified during the execution of the body.

`const` and `pure` are complementary.

This looks actually helpful. It would be even more useful if the compiler could know the global was passed to a const param and enforce the "pure" on just that variable instead of forcing the whole function to be pure.

[440bx]

Well I had higher hopes for const and you seem to be giving justifications for its shortcomings.

I'm not trying to justify the somewhat handicapped functionality of "const" in Pascal but, the fact is, the const-ness of parameters and data in general was not a consideration in the original design of the Pascal language (very obvious from reading J&W's report.)  That's unlike in C.  In C, "const" is a full fledged modifier in type descriptions, it is not that, far from it, in Pascal and, in C that was part of the initial language design. 

It's not fine just because they wrote something in the manual. Const should mean constant.

"const" means "const" in Pascal.  The language does _not_ fail to enforce that. Short of using dirty tricks (which will work in C too) the compiler dutifully enforces data/parameter const-ness.  There is nothing to reproach Pascal in that area.

I did learn some things though, mainly const is basically just like "inline", a hint to the compiler.

No, it is not.  "const" is in no way a hint to the compiler.  It's an order to the compiler telling it to enforce the const-ness of the item and the compiler carries out that function perfectly.

I thought it was something more powerful but it's really nothing more.

It's as powerful as it needs to be.  Whenever it can be specified, it does its job perfectly.

The only thing I can grant you and concede is the absurd "writable constants" thing Borland came up with.  Now, that is a genuine atrocity (which unfortunately reflects very poorly on the language yet, there does not seem to be any desire in the developers to implement a sensible replacement.)  Other than that "writable const" thing, "const" in Pascal is perfectly  fine.

[Martin_fr]

No, it is not.  "const" is in no way a hint to the compiler.  It's an order to the compiler telling it to enforce the const-ness of the item and the compiler carries out that function perfectly.

Read the doc. It is not an order. It is a promise, made by the programmer to the compiler.

The compiler will tell and complain, if it can spot it being broken. But the compiler can do so in a limited scope only.

And - repeating myself - code using const, has crashed entire apps, due to such broken promises. I.e. assigning to a string, that was in a const promise ...

[440bx]

Read the doc. It is not an order. It is a promise, made by the programmer to the compiler.

I know what you're saying and I think it's both.  On one side the programmer promises not to change the value and, on the other side, if the programmer attempts to break that promise, the compiler will follow the implied order to stop any such attempt (of course, limited to those it can detect.)

The compiler will tell and complain, if it can spot it being broken. But the compiler can do so in a limited scope only.

Agreed.

And - repeating myself - code using const, has crashed entire apps, due to such broken promises. I.e. assigning to a string, that was in a const promise ...

That should be expected.  The programmer promised not to change the value, the compiler took the programmer at his/her word, the programmer somehow managed to break that promise without the compiler noticing and... as they say... the bytes hit the fan.

[Joanna]

I don’t understand what the problem is using CONST parameters on things you don’t want changed. I do it all the time. Some things like objects I believe the fields inside can still be changed even if const is used?
Please correct me if I’m wrong.

I brought this up because new languages are doing const by default and looking at my own experience I actually think this is what you want most of the time, thus it should be the default. It's not 1980 anymore and people have decades of experience now to draw from. This is obviously debatable though.

However, I learned a lot in this topic and I don't think this would be safe in Pascal unless the compiler was overhauled to do static analysis of functions and detect they're not actually writing to const parameters. If you made a mistake you could end up with modifying some global state (or member fields) and make a debugging nightmare.

@ryan I’m curious how Long you have used fpc for and how serious you are about using It?
I could care less what “new languages“ are doing.
 I only want to use pascal and for all the years I’ve used it I’ve never ever thought of this as a problem.
If you don’t want a parameters changed inside a procedures, just don’t put a var in front of them. It’s as simple as that. Your request seems like it would be a waste of the developers time at best.

[marcov]

Is it time to make "const" default in Pascal?

For the umpteenth time: such things will never happen due to backwards compatibility concerns. Yes, we can add yet another modeswitch for stylistic concerns, but that proliferation of such switches would be IMHO worse than the actual problem (and then I'm not even counting the work)

[Ryan J]

If const is not incomplete in its implementation then why is "r.x := 100" illegal on a const parameter but "r.SetX(100)" legal? Both do the same thing but the compiler can easily detect := is illegal while the call to SetX is more difficult to detect.

That alone makes default const a non-starter since the compiler doesn't know what is or is not const in the first place.

[Ryan J]

@ryan I’m curious how Long you have used fpc for and how serious you are about using It?
I could care less what “new languages“ are doing.
 I only want to use pascal and for all the years I’ve used it I’ve never ever thought of this as a problem.
If you don’t want a parameters changed inside a procedures, just don’t put a var in front of them. It’s as simple as that. Your request seems like it would be a waste of the developers time at best.

A better question is how old is the history of const in FPC? Is this some feature made up by Delphi 10 years? I never used const until recently and the more I use it the more I realize I feel the need to put it everywhere. Then I notice newer languages without backwards compatibly concerns are making it default and I thought, hey that makes sense to me.

Honestly const could be removed entirely and I wouldn't care too much as it's only an optimization but the cost of using it is messy parameter list.  I feel like I'm doing the work of the compiler anyways adding const to everything over and over again. I'd prefer to have the compiler be smart enough to figure this out itself and forgot about const. maybe that's the way forward? If I recall correctly Jonas has even said he thinks adding "inline" was a mistake so maybe const is the same.

[Ryan J]

Is it time to make "const" default in Pascal?

For the umpteenth time: such things will never happen due to backwards compatibility concerns. Yes, we can add yet another modeswitch for stylistic concerns, but that proliferation of such switches would be IMHO worse than the actual problem (and then I'm not even counting the work)

After talking this over I feel like the compiler should simply be smarter about how to pass certain types. Maybe const isn't even needed.

Look at this code from TFPGObjectList. Why did they need to add "const Item: T"? Did they think it would be faster to pass? If so why doesn't the compiler know how to do this for them?

Code: Pascal  [Select][+][-]

1.  generic TFPGObjectList<T: TObject> = class(TFPSList)
2.   private
3.     type
4.       TCompareFunc = function(const Item1, Item2: T): Integer;
5.       PT = ^T;
6.       TTypeList = PT;
7.       PTypeList = ^TTypeList;
8.       TFPGListEnumeratorSpec = specialize TFPGListEnumerator<T>;
9.   protected
10.     var
11.       FOnCompare: TCompareFunc;
12.       FFreeObjects: Boolean;
13.     procedure CopyItem(Src, Dest: Pointer); override;
14.     procedure Deref(Item: Pointer); override;
15.     function  Get(Index: Integer): T; {$ifdef FGLINLINE} inline; {$endif}
16.     function  GetList: PTypeList; {$ifdef FGLINLINE} inline; {$endif}
17.     function  ItemPtrCompare(Item1, Item2: Pointer): Integer;
18.     procedure Put(Index: Integer; const Item: T); {$ifdef FGLINLINE} inline; {$endif}
19.     function GetLast: T; {$ifdef FGLINLINE} inline; {$endif}
20.     procedure SetLast(const Value: T); {$ifdef FGLINLINE} inline; {$endif}
21.     function GetFirst: T; {$ifdef FGLINLINE} inline; {$endif}
22.     procedure SetFirst(const Value: T); {$ifdef FGLINLINE} inline; {$endif}
23.   public
24.     constructor Create(FreeObjects: Boolean = True);
25.     function Add(const Item: T): Integer; {$ifdef FGLINLINE} inline; {$endif}
26.     function Extract(const Item: T): T; {$ifdef FGLINLINE} inline; {$endif}
27.     property First: T read GetFirst write SetFirst;
28.     function GetEnumerator: TFPGListEnumeratorSpec; {$ifdef FGLINLINE} inline; {$endif}
29.     function IndexOf(const Item: T): Integer;
30.     procedure Insert(Index: Integer; const Item: T); {$ifdef FGLINLINE} inline; {$endif}
31.     property Last: T read GetLast write SetLast;
32.     procedure AddList(Source: TFPGObjectList);
33.     procedure Assign(Source: TFPGObjectList);
34.     function Remove(const Item: T): Integer; {$ifdef FGLINLINE} inline; {$endif}
35.     procedure Sort(Compare: TCompareFunc);
36.     procedure Sort(Compare: TCompareFunc; SortingAlgorithm: PSortingAlgorithm);
37.     property Items[Index: Integer]: T read Get write Put; default;
38.     property List: PTypeList read GetList;
39.     property FreeObjects: Boolean read FFreeObjects write FFreeObjects;
40.   end;
41.  

[440bx]

If const is not incomplete in its implementation then why is "r.x := 100" illegal on a const parameter but "r.SetX(100)" legal? Both do the same thing but the compiler can easily detect := is illegal while the call to SetX is more difficult to detect.

Can you provide a small sample program that demonstrates your statement ?

[marcov]

If const is not incomplete in its implementation then why is "r.x := 100" illegal on a const parameter but "r.SetX(100)" legal? Both do the same thing but the compiler can easily detect := is illegal while the call to SetX is more difficult to detect.

Yes. It is a policy against accidental mistakes, not a state-inside-a-state police force. We don't have access control lists on every identifier either.

But regardless of any downsides, changing a 20 years feature, warts and all is simply not done.

[Joanna]

A better question is how old is the history of const in FPC? Is this some feature made up by Delphi 10 years? 

So I’ll assume you haven’t used pascal for very long ..

I never used const until recently and the more I use it the more I realize I feel the need to put it everywhere.

I added const to most of my parameters too. It’s called getting better at pascal. 

Then I notice newer languages without backwards compatibly concerns are making it default

where would we be if any random person who joined the forums could demand that the fpc compiler could be changed on a whim? That would be the end of the fpc project.

[marcov]

Look at this code from TFPGObjectList. Why did they need to add "const Item: T"? Did they think it would be faster to pass? If so why doesn't the compiler know how to do this for them?

Comparer functions are afaik often const if they can be used for strings or dynarrays. then there are optimization options with const.

[Ryan J]

If const is not incomplete in its implementation then why is "r.x := 100" illegal on a const parameter but "r.SetX(100)" legal? Both do the same thing but the compiler can easily detect := is illegal while the call to SetX is more difficult to detect.

Can you provide a small sample program that demonstrates your statement ?

Sure here's an example. The behavior inconsistent if you ask me. Const protects the fields only on assignments because that's all the information the compiler has. So it kind of helps, but not enough to really trust.

Code: Pascal  [Select][+][-]

1. program test;
2.  
3. type
4.   TMyRec = record
5.     x: Integer;
6.  
7.     procedure SetX(v: Integer);
8.   end;
9.  
10. procedure TMyRec.SetX(v: Integer);
11. begin
12.   x := v;
13. end;
14.  
15. procedure TestRec(const r: TMyRec);
16. begin
17.   r.x := 100;
18.   r.SetX(100);
19. end;
20.  
21. begin
22. end.

[Ryan J]

A better question is how old is the history of const in FPC? Is this some feature made up by Delphi 10 years? 

So I’ll assume you haven’t used pascal for very long ..

I never used const until recently and the more I use it the more I realize I feel the need to put it everywhere.

I added const to most of my parameters too. It’s called getting better at pascal. 

Then I notice newer languages without backwards compatibly concerns are making it default

where would we be if any random person who joined the forums could demand that the fpc compiler could be changed on a whim? That would be the end of the fpc project.

Sigh, instead of making the case for anything and giving insights you pull rank. I think I started using FPC in 2005 after CodeWarrior for macOS was abandoned. I even developed a number of compiler features. That doesn't matter though, any programmer of any language should be able to debate the merits for opt-in const or const by default.