[fpc-pascal] Generic type conflicts
operator97 at gmail.com
Fri Nov 8 17:02:01 CET 2019
On Fri, Nov 8, 2019 at 1:33 AM Michael Van Canneyt <michael at freepascal.org>
> As an aside:
> In my opinion (keep in mind I am not a big fan of generics) the above code
> would be a prime example where one should not be using generics, but
> simple overloads.
> If you need to use GetTypeKind in a generic, I think you're on the wrong
> Use of IsManagedType() in a generic is stretching it, but GetTypeKind() is
> over the line.
I agree to an extent that it's not a *huge* problem and that there are
workarounds in many cases, however there's definitely certain things that
simply cannot be achieved in an equally performant way via any alternative
such as normal overloading.
That said, Ryan's currently-in-limbo patch for constant generic parameters
actually itself in theory already provides proper solutions for quite a few
aspects of the general problem, so even as it stands right now we're at
least making progress towards improving the situation I'd say.
For example, I recently did a translation of the fairly well-known
"PDQSort" algorithm from C++ to Pascal:
The original C++ version used "constexpr" template parameters to determine
at compile time whether or not the user-provided comparison function was
one for which it should use the "branchless" version of its code for item
partitioning or not, and based on that passed the boolean "true" or "false"
result as another constant template parameter.
The end result of course being that the compiled code is always tuned
precisely to the given comparison function, without any kind of runtime
selection based on non-constant boolean function parameters (which is what
I've currently had to write the "branchless" choice as, defaulting to
"true" unless the user specifies otherwise.)
With Ryan's patch, I'll at least be able to write that choice as a constant
parameter instead, although I'm unaware of any way to replicate actually
having the compiler *make* the choice.
So perhaps what's needed is not even necessarily something like "static if"
support, but rather just more compiler intrinsics along the lines of
GetTypeKind / IsManagedType that evaluate different things and return
constant values, which in combination with Ryan's patch will go a long way
as far as increasing the granularity of control available to users of FPC
as far as this kind of stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-pascal