[fpc-pascal] Initialization of constant record member of pointer type

[LacaK]

Dňa 2.12.2020 o 16:09 Tomas Hajny via fpc-pascal napísal(a):
> On 2020-12-02 16:01, LacaK via fpc-pascal wrote:
>> Dňa 2.12.2020 o 13:55 Tomas Hajny via fpc-pascal napísal(a):
>>> On 2020-12-01 11:39, Ladislav Karrach via fpc-pascal wrote:
>>>>>
>>>>> Because MyConst1 is not an *untyped* constant. Only untyped 
>>>>> constants can be used in constant expressions (a pointer to 
>>>>> something can be considered an untyped constant).
>>>>>
>>>>> The following might work though I did not test it:
>>>>>
>>>>> === code begin ===
>>>>>
>>>>> const
>>>>>    MyStr = 'abc'
>>>>>    MyConst1: AnsiString = MyStr;
>>>>>    MyConst2: TMyRec = (l: Length(MyStr); a: @MyConst1[1]);
>>>>>
>>>>>
>>>>> === code end ===
>>>>>
>>>> Yes it works, but I must define 2 constants (MyStr and MyConst1),
>>>> which is not so nice ;-)
>>>>
>>>> It would be nice to have support for true constants:
>>>>
>>>> const
>>>>    MyConst1 = 'abc' ;
>>>>    MyConst2: TMyRec = (l: Length(MyConst1); a: @MyConst1[1]);
>>>>
>>>> But may be that there are technical reasons why it is problematic (may
>>>> be that true constants are stored in another memory locations, which
>>>> can not be easy addressed)
>>>
>>> Yes, that's one of possible reasons.
>>>
>>> Regarding Length in constant value assignment - remember that Length 
>>> is a function. In case of real constants, the call may be replaced 
>>> by the compiler with the constant value. However typed constants may 
>>> not be constant, so generic replacement throughout the source code 
>>> at compile time is not possible (if it appears in the main body or 
>>> some function, the length may already be changed to something else) 
>>> and selective replacement may result in a behaviour not expected by 
>>> the user. The only questionable case is IMHO the case of 
>>> {$WRITEABLECONST OFF} - the compiler _might_ be able to perform the 
>>> compile-time substition in that case (and thus allow using Length of 
>>> such a constant in constant value assignment), but it doesn't do 
>>> that in that case either apparently.
>>
>> Yes I have no problem with {$WRITEABLECONST OFF} if it will allow 
>> Length().
>>
>> Somewhere I read (may be in Delphi documentation) that some intristic
>> functions like Low(), High(), Pred() and also Length() etc. can be
>> used in constant expressions because compiler can evaluate them if
>> theirs arguments are also constants.
>> Which is the case in my example.
>> For now {$WRITEABLECONST OFF} does not help ;-)
>
> Yes, that's what I mentioned as well, but it might be changed for this 
> particular case. You might create a ticket for that if Delphi allows 
> to use Length that way; obviously, you might create such a ticket even 
> if Delphi doesn't allow to do that. ;-)
>
I checked it with older Delphi XE and it seems, that Delphi XE does not 
support Length() for typed constant also when {$WRITEABLECONST OFF}

I do not believe that this will be accepted for FPC, so I don not open 
new feature request in bug tracker.

On other side FPC developers read this mailing list so if they consider 
this as a useful/doable feature may be that someone will take look at it ...

Thanks

-Laco.