[fpc-devel] Implicit function specialization precedence

[Sven Barth]

Am 09.04.2021 um 04:20 schrieb Ryan Joseph via fpc-devel:
>
>> On Apr 8, 2021, at 3:53 PM, Sven Barth <pascaldragon at googlemail.com> wrote:
>>
>> 1. you should not blindly assume that the def is a stringdef if it's not an arraydef; at least use an internalerror to protect against problems here
>> 2. if it's really a stringdef and the return type is st_shortstring you should indeed use SHORTSTRING (it's only constant strings which are a bit more, let's say "dynamic")
>> 3. do an internalerror for st_longstring as those are currently not implemented
>> 4. due to 2. you can move the case of newtype=nil into the if-clause with the arraydef
>>
>> Otherwise, yes, the check for the string type is correct.
> I didn't know how constant strings we identified until just now so I can correct that. Can we make "(def.typ=arraydef) and (ado_isconststring in tarraydef(def).arrayoptions)" into a function in defutils.pas and call it is_constant_string? That  would have been easily visible to me and lead me in the right direction from the start. I also had problems with array literals like [1,2,3] which there is no clear utility function for and prompted me to make is_array_literal() which is private right now (and probably not very correct in design). Moving that to a public space would be sensible also I think.

That is because before the introduction of type helpers such functions 
weren't really needed. Other mechanisms caught such constants, but for 
both type helpers and these implicit specializations it's hard to do it 
another way.

Regards,
Sven