[fpc-devel] Implicit function specialization precedence
Sven Barth
pascaldragon at googlemail.com
Wed Apr 7 21:42:19 CEST 2021
Am 07.04.2021 um 18:16 schrieb Ryan Joseph via fpc-devel:
>
>> On Apr 6, 2021, at 11:34 PM, Sven Barth <pascaldragon at googlemail.com> wrote:
>>
>> In the second case the compiler will have the non-generic Test(String) due to the implicit operator as well as Test<LongInt>(LongInt) due to the implicit specialization. Here it will pick the generic one, because a call without a type conversion is considered better.
> I finally get what you're saying and get the correct results now after moving my check inside the if/then block. I didn't realize that the operator overload was causing a type conversion that the overloading system knew about. So the non-generic still wins unless the type conversion happened due to the operator overload and then the generic wins.
>
> Writeln(Test('Hello World')); // Test(String)
> Writeln(Test(42)); // Test<String>
> Writeln(Test(String(42))); // Test(String)
Good. :)
> As for $H+ do we really want string literals likes 'ABC' to change? I wouldn't think so. Here's my string literal type symbol conversion in create_unamed_typesym I'm using now:
>
> case tstringdef(def).stringtype of
> st_shortstring:
> newtype:=search_system_type('SHORTSTRING');
> st_longstring,
> st_ansistring:
> newtype:=search_system_type('ANSISTRING');
> st_widestring:
> newtype:=search_system_type('WIDESTRING');
> st_unicodestring:
> newtype:=search_system_type('UNICODESTRING');
> end;
>
> 'Hello World' is parsed as st_shortstring so we use System.ShortString for specialization. Given that I don't think I need to do anything with $H+.
Yes, we want to change that for two reasons:
- the constant string might be larger than 255 characters
- ShortString is worse for passing as a by-value parameter (which will
be the default after all) than AnsiString or UnicodeString as
ShortString is completely copied while Ansi-/UnicodeString are only
references with reference count adjustments
Also your check is wrong as the def that returns True for is_stringlike
might not be a stringdef. In the case of a constant string it's an
arraydef with ado_ConstantString in arrayoptions (and that's how you can
detect constant strings which *need* this treatment).
Regards,
Sven
More information about the fpc-devel
mailing list