[fpc-devel] Implicit function specialization precedence

[Ryan Joseph]

> 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;

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


Regards,
	Ryan Joseph