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

[Marc Weustink]

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)), ...


Marc