LazUtils: consider to add 'const S' for these string funcs

[440bx]

And for structures, if it is about optimization, then you would not care if it is by ref, so const will be better, as the compiler can generate whatever performs better.

For structures that are larger than what fits in a register, it is about optimization and, in that case, "constref" is what should be preferred because it ensures the structure is passed by reference.

That's in stark contrast with just "const" which does _not_ require the compiler to pass by reference.  When the structure is "const" and larger than what fits in a register, FPC is currently passing it by reference but that's an internal compiler optimization, not what "const" means.  The documentation even specifically states that, unlike in Delphi, the use of "const" should _not_ be presumed as causing the compiler to pass by reference.  Semantically and strictly, "const" does _not_ imply anything as to how a parameter is passed.

Being clear and explicit is always best.  "constref" is what should be used when a constant structure should be passed by reference (more often than not, due to that being optimal), not "const" because "const" may or may not cause passing by reference, not to mention that presuming it will cause passing by reference is inherently incorrect and unreliable.

[marcov]

const should be optimal for the architecture, allowing to load small records in multiple registers or vector registers.

constref is mostly for flagging external (to other languages, and to assembler) to force a certain way. IMHO it shouldn't be used otherwise.

[440bx]

const should be optimal for the architecture, allowing to load small records in multiple registers or vector registers.

constref is mostly for flagging external (to other languages, and to assembler) to force a certain way. IMHO it shouldn't be used otherwise.

I think it is the opposite of that.  Here is the remark about constant parameters in the FPC reference guide:

Remark Contrary to Delphi, no assumptions should be made about how const parameters are passed to
the underlying routine. In particular, the assumption that parameters with large size are passed by
reference is not correct. For this the constref parameter type should be used, which is available
as of version 2.5.1 of the compiler.
An exception is the stdcall calling convention: for compatibility with COM standards, large const
parameters are passed by reference.

"const" only means the item is constant.  It says _nothing_ about how the item is passed.  If the item should, for any reason, optimization or otherwise, be passed by reference then "constref" is the correct modifier.

[marcov]

const should be optimal for the architecture, allowing to load small records in multiple registers or vector registers.

constref is mostly for flagging external (to other languages, and to assembler) to force a certain way. IMHO it shouldn't be used otherwise.

I think it is the opposite of that.  Here is the remark about constant parameters in the FPC reference guide:

Remark Contrary to Delphi, no assumptions should be made about how const parameters are passed to
the underlying routine. In particular, the assumption that parameters with large size are passed by
reference is not correct. For this the constref parameter type should be used, which is available
as of version 2.5.1 of the compiler.
An exception is the stdcall calling convention: for compatibility with COM standards, large const
parameters are passed by reference.

"const" only means the item is constant.  It says _nothing_ about how the item is passed.  If the item should, for any reason, optimization or otherwise, be passed by reference then "constref" is the correct modifier.

What I say is exactly the reason for this policy.  But 32-bit X86 is an exception due to its multiple generations of calling conventions.  Luckily more and more people change to 64-bit nowadays.

[Martin_fr]

That's in stark contrast with just "const" which does _not_ require the compiler to pass by reference.  When the structure is "const" and larger than what fits in a register, FPC is currently passing it by reference but that's an internal compiler optimization, not what "const" means.  The documentation even specifically states that, unlike in Delphi, the use of "const" should _not_ be presumed as causing the compiler to pass by reference.  Semantically and strictly, "const" does _not_ imply anything as to how a parameter is passed.

I am not arguing if the documentation is good or not, or accurate or not...

I am also not arguing about the naming: Is "const" the best name? Apparently that depends on associations different people have from different backgrounds.

Applying solely the understanding that I have from the docs (as I comprehend them, and as I have been told they should be comprehended): "const" is about optimization, and optimization only. The name "const" signifies that I (the user) will keep the value unchanged (for the duration of the call).

So to me, the name describes what it does.

If you come from C, it may mean something else to you (but then a lot will do that).

If you hoped for a different feature, then yes the name can be interpreted in different ways. But since the feature you hoped for, and the feature we got, both include a concept of "something being constant" => I would guess most names can be misinterpreted.

And let it be known: I absolutely support your quest for the other feature.
I am just majorly confused, why that quest needs to brand-mark the current feature as somehow wrong or bad. It should be an independent feature. So it should have no impact on the current feature (other than that the compiler could use overlaps to make even more/better optimization if it turns out to be possible, but the feature you want does in no way need to limit the current feature)

Being clear and explicit is always best.  "constref" is what should be used when a constant structure should be passed by reference (more often than not, due to that being optimal), not "const" because "const" may or may not cause passing by reference, not to mention that presuming it will cause passing by reference is inherently incorrect and unreliable.

Yes, exactly. And that is why one might use "const" => I might not care if it is by reference. I care that it is passed efficiently.

If TPoint can be passed in 2 of 32 bit registers, and if that turns out to be more efficient => then do it that way. (don't know if that would actually happen / don't need to know / someone with knowledge embedded that into the compiler).

But yes, if I want and need a ref, then I know to use constref (or var).

But if I use "constref" then I also know, it may not be passed in the most efficient way. I chose that it may be inefficient.

[440bx]

You mentioned C and one of the things that has become evident is that FPC users have acquired a tendency to make associations that are logically incorrect.

"const" declares that the item is immutable.  It does NOT mean that some optimization will be done or that some optimization should be expected or done.  The only valid expectation about declaring an item to be "const" is that the compiler will not allow an assignment to that item.  That's it, nothing else.  Optimization(s) that may happen are optional and completely implementation dependent.   The compiler could pass the parameter by value and, as long as it doesn't allow an assignment to be made to that parameter, it has faithfully honored the parameter constness. 

"const" does not mean "pass by reference", "optimize this or that".  It only means what the word says: constant.  Yes, it just so happens that the C language does NOT mix apples and oranges, such as how a parameter is passed and whether or not the parameter is const.  Those are two very different things. It's kind of nice when apples and oranges are kept separate.

I'm not arguing either.  I just like the words to mean what they are supposed to mean and not be redefined for rather dubious reasons (shades of writable constants.)

[Martin_fr]

"const" declares that the item is immutable.  It does NOT mean that some optimization will be done or that some optimization should be expected or done.

Who says so? That is with regard to the latter part? (the latter part is ultimately just a consequence of the const/immutability)

Neither saying "const" nor "immutable" declares why it should be in such state, or what that state should enable to happen. => i.e. the should the declared state cause the compiler to throw errors, or should it cause the compiler to optimize? Well, what it should, is what the docs say.

No one argues that the item isn't "immutable": In fact, "const" means I promise to the compiler that the item should be assumed immutable for the time being.

It's not about the term we use for the "not changing its value" state. Its about if that state is cause or effect => that is not derived from the word, but from the docs.

[Martin_fr]

I don't know why you attack that feature (really don't).

Do you not like it, if someone can specify optimizations? (what about the "inline" modifier?)

Or do you not like the name, ie. would you rather see
  procedure Foo(optimize_for_no_write_access   s: string);
?

I do understand you want a feature where you can say: Dear compiler please check that this is immutable. And I already said => that is a good idea.
But that does not conflict with the current feature (unless you don't just want that feature, but you want it with the current keyword, and the current keyword only).

[440bx]

I don't attack the "const" feature. 

What I "attack" (I feel that's a bit overstated), is the presumption, expectation or assumption that a "const" item means or requires the compiler to pass the item by reference in some cases.

In NO case whatsoever does "const" force (or require) the compiler to pass the item by reference.  The item can be passed by value and, as long as the compiler disallows something to be assigned to the item, the "const" property has been upheld.

There is a reason there is "constref" in addition to const.  The reason is because "constref" tells the compiler to pass the constant by reference something which "const" does NOT require.

I like words to mean what the _dictionary_ says they mean and when I look up "constant" in a dictionary, no dictionary I've ever seen says: "a parameter that will be passed by reference".   I suspect the reason is because "const" or "constant" does NOT mean passing by reference.  It only means: it's immutable.

Let apples be apples and if you want oranges ask for oranges not for apples.  IOW, you want const ask for const, you want const passed by reference ask for constref not const.

The problem is that in Pascal the incorrect association of "const" meaning pass by reference, in addition to immutable, has become accepted and expected.

[marcov]

The only valid expectation about declaring an item to be "const" is that the compiler will not allow an assignment to that item.  That's it, nothing else.  Optimization(s) that may happen are optional and completely implementation dependent.

All true, but to let optimization actually happen and to adjust to circumstances (read: architecture that might have alignment requirements and many more registers than 32-bit x86) , you need to give the compiler room.

CONSTREF is hemming the compiler in. That is good if you need for some reason enforce some contract with the callee, but that is a special case.

This has nothing to do with C, but is a general rule of ABIs.

[440bx]

CONSTREF is hemming the compiler in. That is good if you need for some reason enforce some contract with the callee, but that is a special case.

Actually, "constref" is a programmer specified optimization.  It is telling the compiler: this item is constant and I want you to pass it by reference (instead of by value which the compiler would be in its right to do if it so chose.)

This has nothing to do with C,

Yes and no.

I mentioned C because C uses "const" as it should be used, i.e, as part of the data type, which is much more powerful, useful and descriptive.  (I can't believe I'm "defending" C.)

[Martin_fr]

Replied in order of reading. Skip forward to the 2nd bold "presumption", when looking at my first reply to it.

I don't attack the "const" feature. 

Sorry, then. this was merely an attempt to say, you seem to express some disagreement in relation to it. At least that is what I receive.

What I "attack" (I feel that's a bit overstated), is the presumption, expectation or assumption that a "const" item means or requires the compiler to pass the item by reference in some cases.

Ok, then I must have missed some part of the conversation. But I did not note that "association" being expressed (until you brought it up).

In fact this post by you https://forum.lazarus.freepascal.org/index.php/topic,72779.msg570355.html#msg570355
is the first to mention any word containing "ref".

Also to be clear, from your quote "requires ... to pass by ref"

"const" may allow the compiler to pass by ref. But to the best of my knowledge, it certainly does not "require" it ("stdcall" does require it / in combination / that is a bit problematic that the keyword gets a 2nd meaning here). I.e. the doc  https://www.freepascal.org/docs-html/ref/refsu67.html says " the assumption that parameters with large size are passed by reference is not correct."

In NO case whatsoever does "const" force (or require) the compiler to pass the item by reference.  The item can be passed by value and, as long as the compiler disallows something to be assigned to the item, the "const" property has been upheld.

Ah, well, I thought I had seen it when I looked it up in the docs

There is a reason there is "constref" in addition to const.  The reason is because "constref" tells the compiler to pass the constant by reference something which "const" does NOT require.

Here you loose me?

Now you say "const" does not require passing by ref...

Ok, so about your "presumption" quote above: Did you then mean
-> you don't like users to assume that (because it is wrong)
-> so the entire (part of) the conversation, wasn't about the feature, but about (what you think) other users presume?

Sorry, I might have gotten you all wrong here... I am trying not to.

I like words to mean what the _dictionary_ says they mean and when I look up "constant" in a dictionary, no dictionary I've ever seen says: "a parameter that will be passed by reference".   I suspect the reason is because "const" or "constant" does NOT mean passing by reference.  It only means: it's immutable.

Neither does any dictionary (not a compiler or language doc, a dictionary) say: "a parameter that is enforced by the compiler not to be changed"

Constant in a dictionary just explains: something that does not change. That may be for any reason, that may be cause or effect, that may be controlled or not, that depends on the item that is constant, and the context in which it is constant.

The fact that 2+2=4 does not mean that I couldn't write 2+2=5. It just is wrong, and if I use that as a base for further work, then I will get errors.
Same about "const", It doesn't mean I can't break it (in any language that has pointers, as soon as it is in memory, I can just swipe the entire memory with random data, and the const will change => the effects will be catastrophic).

Let apples be apples and if you want oranges ask for oranges not for apples.  IOW, you want const ask for const, you want const passed by reference ask for constref not const.

I fully understand the diff between const and constref.

Unless you are (other than you said) contest (to avoid "attack") the part that says "allows the compiler to pass by ref".

But, that would be an implementation detail. If implemented according to the docs (i.e. the value is not changed) then my code will always work the same, never mind if the compiler passes it one way or another.

In the same way, some compilers will optimize
   for x := 0 to large do
      write(10*x);
by changing the multiplication to an addition (counter with step 10).
==> But I did clearly ask for multiplication, did I not?

The problem is that in Pascal the incorrect association of "const" meaning pass by reference, in addition to immutable, has become accepted and expected.

Well, all I can say is that
1) I don't have that association.
2) I haven't seen many posts that gave me the impression their authors do.

But that is my perception of what others may think versus your perception.

My perception though is that a lot of people expect
- the optimization effects of "const" param, to be massively larger than they are
- are unaware of lots of details on how to use it correctly

[Martin_fr]

Let apples be apples and if you want oranges ask for oranges not for apples.  IOW, you want const ask for const, you want const passed by reference ask for constref not const.

Unless you are (other than you said) contest (to avoid "attack") the part that says "allows the compiler to pass by ref".

But, that would be an implementation detail. If implemented according to the docs (i.e. the value is not changed) then my code will always work the same, never mind if the compiler passes it one way or another.

To make my point even clearer:

- If I use "constref" the compiler MUST pass by const.
- If I do not use constref (and there is no modifier "ForcePassByVar"), then the compiler can freely (well within below limits) decide.

The latter means that even in

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

1. procedure Foo(Val: TSomeType);

the compiler is free to pass Val by either value or reference, if it can make sure that passing by ref does not change the behaviour. Of course, FPC can't currently decide that. And for a compiler to detect that very quickly becomes very complex.

Of course the calling convention must allow it too, and it can't be an external call (e.g to a library).

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

1. procedure Foo(Val: TSomeType);
2. begin
3.   write(Val.FSomeField);
4. end;
5.  

Can safely have Val passed by ref. Even in a threaded environment, even if other threads have access (because any race can equally happen before the copy for pass-by-val is taken).

If the code was inlined (which the compiler could do, with AUTOINLINE) there would be no copy of the value made either.

[440bx]

I like words to mean what the _dictionary_ says they mean and when I look up "constant" in a dictionary, no dictionary I've ever seen says: "a parameter that will be passed by reference".   I suspect the reason is because "const" or "constant" does NOT mean passing by reference.  It only means: it's immutable.

Neither does any dictionary (not a compiler or language doc, a dictionary) say: "a parameter that is enforced by the compiler not to be changed"

Here is (one of) the dictionary definitions of "constant":

a situation or state of affairs that does not change.

That definition applies to a compiler constant just as it does to anything else.  (well, in all fairness, Pascal has writable constants so, there is at least one additional problem associated with Pascal's creative definition of what is a constant.)  IOW, the definition in the dictionary is definitely something the compiler is _expected_ to abide by (just as anything else that claims that something is constant.)

It would be really nice if the compiler honored the meaning of the words it uses, "const" among them.

As far as the rest goes...

In the first few replies in this thread, there is an _implication_ that the use of "const" would produce better code, IOW, it would allow the compiler to perform optimizations it cannot do otherwise.

The point I made in my first post and, that I maintain, is that "const" should NOT be used to cause the compiler to perform some optimization.  "const" should be used to document how an item is used, nothing else.  IF the programmer wishes to have the compiler "optimize" how the parameter is passed, which normally means by reference, then the programmer should specify "constref" which does two things: 1. it tells the the compiler to perform the optimization and 2. it gives the compiler a chance to emit a message if for whatever reason a reference to the item cannot be used.  "const" does NOT do that.  It is an inferior, deficient and incorrect way of getting the pass by reference optimization.  It is all those things because "const" does NOT mean nor imply nor require passing by reference, therefore that action should NOT be expected of it.

why am I so picky about it ? ... there are several reasons:

1. the documentation _specifically_ states that "const" should NOT be expected to pass a parameter by reference.
2. the documentation _specifically_ states that if passing by reference is desired/required then "constref" should be used.
3. I've seen _plenty_ of FPC code that _incorrectly_ assumes using "const" causes passing by reference (and unfortunately in those cases it does)

As far as point 3 above, an example of that is the passing of IIDs and specifically the incorrect definition of REFIID as NOT being a pointer to a GUID.  Instead the definition pretends a REFIID is a GUID and _wrongly_ depends on "const" (instead of "constref") to cause the compiler to pass by reference.  Every single one, without exception, of those definitions is incorrect because it assumes behavior associated with "const" that is NOT part of what a constant is by definition (at least a rational, logical, mathematically correct, definition.)

The REFIID is the one example that stands out in my mind because I consider it appalling but, it isn't the only case I've seen but, I cannot forget that one.  For the record, I am not trying to blame any FPC member developer about this situation.  I believe those "creative' definitions are such to follow Delphi's suit. 

Lastly, I believe a programmer is supposed to tell the compiler what it should do and do so with a high level of precision and accuracy. IOW, there are choices the compiler should NOT ever be allowed to make because it is the programmer's responsibility to make them, among those is how a parameter is passed: by reference or by value (if that wasn't the case then why does the language even have "var"... get rid of "var" and have the compiler be "free" to make the decision... because, of course, the compiler always knows better... maybe in some cases it does... depends on the programmer. )

To summarize,

1. I don't have anything against "const".
2. I have a problem with "const" being _misused_ to trigger one or more compiler optimizations.  That's NOT what "const" is for.
3. if a const should or needs to be passed by reference, there is a modifier for that: "constref", use it, that's what it's there for.

Hopefully, this const subject does not need further elaboration.  It should be a dead "const" by now.

[Martin_fr]

Here is (one of) the dictionary definitions of "constant":

a situation or state of affairs that does not change.

Pretty much exactly what I said it would be...

That definition applies to a compiler constant just as it does to anything else.  (well, in all fairness, Pascal has writable constants so, there is at least one additional problem associated with Pascal's creative definition of what is a constant.)  IOW, the definition in the dictionary is definitely something the compiler is _expected_ to abide by (just as anything else that claims that something is constant.)

It would be really nice if the compiler honored the meaning of the words it uses, "const" among them.

And that also defines very much the information "I, the uses, will not change that, therefore it is constant. While you, the compiler, can not check for that, please believe me and use the information as you are pleased"
That says exactly: The value is constant.

And it says to the compiler: Abide or conform to that. I tell you, you conform with it.

The current implementation is exactly as the dictionary implies.

Please, take the exact one sentence you said was from the dictionary, and explain how that sentence says anything about "enforced by the compiler", and can according to you not mean "enforced by the user"
=> actually that sentence does not even say anything about enforcing.
=> that sentence just states the result "does not change"
  and when the user does ensure it does not change it, then that result is achieved.

So how do you get anything else out of that dictionary definition?

As far as the rest goes...

In the first few replies in this thread, there is an _implication_ that the use of "const" would produce better code, IOW, it would allow the compiler to perform optimizations it cannot do otherwise.

Yes, they did. And yes that is true. That is what the const modifier does. Give the compiler the additional knowledge that the value will be const. So the compiler can use (conform/abide to) that knowledge.

But, those replies did not (as far as I can see) say, that this optimization is expected to be passing by ref with the indent to conform to some "by ref" calling convention.

There is a difference between calling by ref, as a functional change (the callee actually makes needs a ref). And using a ref as optimization, without any change to behaviour. The latter may be calling by ref, but the expectation is not about the ref, but about the performance.

The point I made in my first post and, that I maintain, is that "const" should NOT be used to cause the compiler to perform some optimization.

Why?

We have other hints to allow optimizations, e.g. inline.

It does not conflict with the dictionary meaning of the word "const".

Since it does not trigger a specific optimization, but rather allows generally for various optimizations, the keyword can not be based on the optimization itself.
Therefore the keyword simple states the fact (this value is const / I the user have made sure of it), and then leaves the compiler the freedom to deal with it.

Just like the compiler can replace a multiplication with a counter, by an addition of the step value. I get the result that the multiplication would give me. But I don't actually get the code that does the multiplication.

"const" should be used to document how an item is used, nothing else.

Interesting.

Because, I thought you wanted "const" to tell the compiler to check that this use case is obeyed? But that would be "something else".

If there truly is "nothing else", then why even bother telling the compiler.

If there is, then the word "const" as in the dictionary, does not disqualify either choice. So out of the 2 possible "something else", the current one is a valid choice.

  IF the programmer wishes to have the compiler "optimize" how the parameter is passed, which normally means by reference, then the programmer should specify "constref"

That is wrong.
Optimize does not "normally mean by reference".

That is just one of many optimization that may or may not be applied.

And a lot of times people use const for the "omit managed type refcount" optimization.

There a plenty of cases where users use "const" especially for ansistring.
- Passing an ansistring by reference (reference to the internal pointer / aka truly double reference) is not what is wanted then
- not doing the InterLockedIncrement is what is wanted

So, no: const is not "normally" used as a means to want "by reference"

And it isn't in this thread here, since this was about ansistrings.

1. the documentation _specifically_ states that "const" should NOT be expected to pass a parameter by reference.

Yes, I agreed.

And, I have not seen anyone expecting this. Please show where someone expects this.

3. I've seen _plenty_ of FPC code that _incorrectly_ assumes using "const" causes passing by reference (and unfortunately in those cases it does)

"Plenty" ... How is that defined? More than how many percent of the uses of "const param"?

Also, there is a difference between individual uses of a feature and the feature itself. If there are some incorrect uses, then thats a problem for them, not for the feature.

And well, yes, next is "but if the feature invites it" => lets also get rid of asm, pointer, utf8, .... All of them invite mistakes (by some definition, that can be made up).

As far as point 3 above, an example of that is the passing of IIDs and specifically the incorrect definition of REFIID as NOT being a pointer to a GUID.  Instead the definition pretends a REFIID is a GUID and _wrongly_ depends on "const" (instead of "constref") to cause the compiler to pass by reference. 

Ok, I don't know where that code is.

But, then (if you are right) that would be ONE wrong use. And maybe there are some other.

The majority of use cases that I have seen for "const" param, are not wrong (in the sense that they should be constref).

In fact, the majority of uses of "const param" would be wrong, if they were changed to constref. Because many of them want to be "pass by value", but rely on other optimizations done by "const"

E.g. any use of "const" with "ansistring", or dyn-array, or open-array => all of those definitely do not want "pass by ref"
And those are plenty.

1. I don't have anything against "const".
2. I have a problem with "const" being _misused_ to trigger one or more compiler optimizations.  That's NOT what "const" is for.
3. if a const should or needs to be passed by reference, there is a modifier for that: "constref", use it, that's what it's there for.

(2) is exactly what it is for. That is
- documented
- does not conflict with the dictionary

(3) I have agreed on the "need" part several times.

"should" is ambiguous as it can include "happens as a side effect". And side effects, that do not alter the behaviour of the code, well they are everywhere, so I don't see why this one would be special. (as long as it is not mixed with the "functional required" feature).