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

[Sven Barth]

Am 14.12.2020 um 09:08 schrieb Marc Weustink via fpc-pascal:
>
>
> On 4-12-2020 13:01, LacaK via fpc-pascal wrote:
>>
>> 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 
>
> I just happened to write a construct like this (in Delphi):
>
> const
>   X_0: array[0..4276] of SmallInt = (.....
>
>   MAP: array['0'..'9'] of TSomething = (
>     (Samples: @X_0; Count: Length(X_0)), ...

That works, because the size of the *type* is known at compile time. 
String data however is not part of the type, it's content.

Regards,
Sven