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@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
