> On Apr 8, 2021, at 11:37 PM, Sven Barth via fpc-devel
> <fpc-devel@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
