[fpc-devel] Implicit function specialization precedence

[Sven Barth]

Am 09.04.2021 um 18:12 schrieb Ryan Joseph via fpc-devel:
>
>> On Apr 8, 2021, at 11:37 PM, Sven Barth via fpc-devel <fpc-devel at lists.freepascal.org> wrote:
>>
>> 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.
> Ok then I'll add a is_constant_string function for later use.
>
> What about this function I'm using, should it be in defutils.pas also? I need this so I can distinguish "unnamed array literals" like ['a','b','c'] from short strings like 'abc'. They may be internally identical to arrays but conceptionally they are different. Not sure about the naming so I chose "array literal" but "anonymous array" would make sense also.
>
>        function is_array_literal(def:tdef): boolean;
>          begin
>            result := (def.typ=arraydef) and not is_constant_string(def);
>          end;

This will lead to false assumptions, cause it will return True for *any* 
arraydef that's not a constant string.

> Btw, this block (from create_unamed_typesym) could be a useful helper function in tstringdef, such as "get_default_system_type". I needed something similar to get the char type for a string def (and added that method already) so this is another logical extension to that.
>
> case tstringdef(def).stringtype of
>                st_shortstring:
>                  newtype:=search_system_type('SHORTSTRING');
>                { st_longstring is currently not supported but
>                  when it is this case will need to be supplied }
>                st_longstring:
>                  internalerror(2021040801);
>                st_ansistring:
>                  newtype:=search_system_type('ANSISTRING');
>                st_widestring:
>                  newtype:=search_system_type('WIDESTRING');
>                st_unicodestring:
>                  newtype:=search_system_type('UNICODESTRING');
>              end

Possibly, yes...

You could provide the various utility functions in a separate patch.

Regards,
Sven