Recent

Author Topic: Explicit generic specialization  (Read 1063 times)

OkobaPatino

  • Full Member
  • ***
  • Posts: 191
Explicit generic specialization
« on: November 29, 2020, 06:20:14 pm »
Does FPC supports explicit generic specialization?
https://en.cppreference.com/w/cpp/language/template_specialization

PascalDragon

  • Hero Member
  • *****
  • Posts: 2595
  • Compiler Developer
Re: Explicit generic specialization
« Reply #1 on: November 30, 2020, 10:14:40 am »
No.

OkobaPatino

  • Full Member
  • ***
  • Posts: 191
Re: Explicit generic specialization
« Reply #2 on: November 30, 2020, 10:43:27 am »
Will we have it? Is there an issue for it? For example, I like to have a generic function and another one handling pointers or arrays. As of now, you can not have two generic methods with the same name that are using each other, and one gets "T" and the other gets "array of T".
For example, you can not do this, but if there was a way to make a version of the method for arrays explicitly, it would be possible.

Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. {$mode delphi}
  4.  
  5.   procedure Test<T>(A: T); overload;
  6.   begin
  7.     WriteLn(A);
  8.   end;
  9.  
  10.   procedure Test<T>(A: array of T); overload;
  11.   var
  12.     I: Integer;
  13.   begin
  14.     for I := Low(A) to High(A) do
  15.       Test<T>(A[I]);
  16.   end;
  17.  
  18. begin
  19.   Test<Integer>(1);
  20.   Test<Integer>([1, 2, 3]);
  21.   ReadLn;
  22. end.                                          

Thaddy

  • Hero Member
  • *****
  • Posts: 10684
Re: Explicit generic specialization
« Reply #3 on: November 30, 2020, 12:25:59 pm »
T can also legally be TArray<T> (which is array of T), so the compiler can not determine which overload to call.
IOW it is ambiguous. This goes for both open array of T - as you use - as for TArray<T>
« Last Edit: November 30, 2020, 12:32:00 pm by Thaddy »

OkobaPatino

  • Full Member
  • ***
  • Posts: 191
Re: Explicit generic specialization
« Reply #4 on: November 30, 2020, 12:39:21 pm »
Your point is valid, and I know that. If you do not use them in each other, things go okay.
One of the usages I have in mind for Explicit specialization is making a particular version of a generic.

PascalDragon

  • Hero Member
  • *****
  • Posts: 2595
  • Compiler Developer
Re: Explicit generic specialization
« Reply #5 on: November 30, 2020, 01:07:17 pm »
Will we have it?

No, it is not planned.

OkobaPatino

  • Full Member
  • ***
  • Posts: 191
Re: Explicit generic specialization
« Reply #6 on: November 30, 2020, 03:25:15 pm »

Thaddy

  • Hero Member
  • *****
  • Posts: 10684
Re: Explicit generic specialization
« Reply #7 on: November 30, 2020, 07:50:08 pm »
It is not a bug but a feature request.
I also wonder why we need it.
C++ templates are overly engineered anyway. And prone to error.
I use C++ a lot, more so than FPC, but that language s*cks.

OkobaPatino

  • Full Member
  • ***
  • Posts: 191
Re: Explicit generic specialization
« Reply #8 on: November 30, 2020, 09:08:02 pm »
I gave an example. There is no way now that you can both function with the same name and overloaded. Not much, but it is limiting.
I will be glad to have another way to solve this.
« Last Edit: December 04, 2020, 07:50:43 pm by OkobaPatino »

Leledumbo

  • Hero Member
  • *****
  • Posts: 8286
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Explicit generic specialization
« Reply #9 on: December 04, 2020, 05:18:29 am »
I gave an example. There is no way now that you can both fucktion with the same name and overloaded. Not much, but it is limiting.
I will be glad to have another way to solve this.
I wonder why would you. In what real world case that you need a function with the same name where one handles 1 instance while the other expects an array of it? I would only make the latter if the semantic of the singular is basically the same as the array one. Otherwise, I don't think they belong to the same name.

OkobaPatino

  • Full Member
  • ***
  • Posts: 191
Re: Explicit generic specialization
« Reply #10 on: December 04, 2020, 07:56:41 pm »
It can be useful in case of having a list, you can make two Add. One gets one item and the other one gets an array for bulk operation. Yes I can make Add and AddMany for example but it is more clear to have them under the same name.
Or for another example, having Sum function that one gets two items and another one gets two arrays.
This is not just limited to arrays, maybe you like to have the function for pointers too.
All I explained, can be made with different names, but it is more consistent to have them with the same name, eg add, sum.

PascalDragon

  • Hero Member
  • *****
  • Posts: 2595
  • Compiler Developer
Re: Explicit generic specialization
« Reply #11 on: December 04, 2020, 11:16:47 pm »
Please note that the example you provided earlier (see below) does not require any explicit specialization, cause after I fixed a bug in revision 47686 the overload resolution of FPC lets it compile and run correctly.

Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. {$mode delphi}
  4.  
  5.   procedure Test<T>(A: T); overload;
  6.   begin
  7.     WriteLn(A);
  8.   end;
  9.  
  10.   procedure Test<T>(A: array of T); overload;
  11.   var
  12.     I: Integer;
  13.   begin
  14.     for I := Low(A) to High(A) do
  15.       Test<T>(A[I]);
  16.   end;
  17.  
  18. begin
  19.   Test<Integer>(1);
  20.   Test<Integer>([1, 2, 3]);
  21.   ReadLn;
  22. end.

OkobaPatino

  • Full Member
  • ***
  • Posts: 191
Re: Explicit generic specialization
« Reply #12 on: December 05, 2020, 02:13:43 pm »
It seems I was asking for more than I needed. Your fix made my issue away.
Thank you very much.

PascalDragon

  • Hero Member
  • *****
  • Posts: 2595
  • Compiler Developer
Re: Explicit generic specialization
« Reply #13 on: December 05, 2020, 04:33:37 pm »
Well, your feature request helped to find a bug, so there's that. ;D

OkobaPatino

  • Full Member
  • ***
  • Posts: 191
Re: Explicit generic specialization
« Reply #14 on: December 05, 2020, 04:34:52 pm »
And thanks to you for fixing that ;)

 

TinyPortal © 2005-2018