Modeswitch for no "specialize" keyword like in Delphi mode

[Fibonacci]

What is the modeswitch so I can specialize generic type without the "specialize" keyword? Like calling "myvar: TArray<String>" instead of "myvar: specialize TArray<String>"?

[jamie]

Delphi

[Fibonacci]

Thats a {$mode xxx}, not a {$modeswitch xxx}.

BTW, about modeswitches. I didnt know about it until today, get this.. "-M" switch sets the mode, like objfpc, delphi etc., but did you know you can also set modeswitches with "-M"? Like "-Marrayoperators"? And it works per whole project, in all the files. But there is one downside, if in the unit you set {$mode xxx} (and it is done by default when you create a new unit) then it will reset all the modeswitches to that specific mode, so then the "-Marrayoperators" wil be overwritten and wont work.

Is it documented that you can use "-M" with modeswitches?

[Leledumbo]

But there is one downside, if in the unit you set {$mode xxx} (and it is done by default when you create a new unit) then it will reset all the modeswitches to that specific mode, so then the "-Marrayoperators" wil be overwritten and wont work.

The prioritization is logical, IMHO. If a mode[switch] or basically any compiler directive is present in a compilation unit, then the code there is designed to work with that directive. This allows you to override the directive for any other units except those that declare one themselves.

Is it documented that you can use "-M" with modeswitches?

Yes, which is the output of `fpc -h`. `fpc -i` also lists available modeswitches.

[PascalDragon]

What is the modeswitch so I can specialize generic type without the "specialize" keyword? Like calling "myvar: TArray<String>" instead of "myvar: specialize TArray<String>"?

There is none. It's coupled to mode Delphi directly.

[Okoba]

Why?
It helps readability a lot. I like use objfpc but this limitation forces me to use delphi.

[jamie]

Why?
It helps readability a lot. I like use objfpc but this limitation forces me to use delphi.

I believe that is UNIT based. In other words, if you move your generic definitions and some code in a unit by itself using mode Delphi then the use of that
in other units should allow you to use them without the SPECIALIZE.

I am only going by memory which seems to be short these days.

Jamie

[Warfley]

Why?
It helps readability a lot. I like use objfpc but this limitation forces me to use delphi.

Well... Does it?

Code: Pascal  [Select][+][-]

1. generic function Iterate<T, U>(const ADictionairy: specialize TDictionary<T, U>): specialize IIterator<Generics.Collections.specialize TPair<T, U>>;

Versus:

Code: Pascal  [Select][+][-]

1. generic function Iterate<T, U>(const ADictionairy: TDictionary<T, U>): IIterator<Generics.Collections.TPair<T, U>>;

[bytebites]

Delphi-mode doesn't accept generic keyword.

[PascalDragon]

Why?
It helps readability a lot. I like use objfpc but this limitation forces me to use delphi.

It makes things much easier for the parser. There is quite some Delphi code that FPC's parser in mode Delphi simply can't handle as of now. In mode ObjFPC there is no problem due to the use of specialize.

[Martin_fr]

It helps readability a lot. I like use objfpc but this limitation forces me to use delphi.

Does it? Define readability, without bias of your personal habits.

If a user who is not familiar with either Syntax reads the code, then the English words generic/specialize are likely a huge help to them. They may not immediately spot the special <> brackets, as brackets rather than comparison, and if the do they may not in all cases be sure if its a declaration or specialization.

Leaving them away, could be seen as similar to arguing that one could (in English) in some case omit personal pronouns. Why do I need write "I am doing this"? The "I" is redundant, the verb form "am" states on its own that I talk about myself. Yet "am doing that" is not more readable.

Or in coding terms, 10 loops using i0 to i9 versus well named variables?
Sure you can fit more onto your screen, but so can you with a 3 point sized font => yet not more readable, or is it?

If your code gets to long, and can't be read without all parts of it on the screen, then the problem is at some other point. Maybe factor out some of the code into named routines... Or some other refactoring...

[Okoba]

@PascalDragon is there a possibility for having this as a mode switch so I can keep using objfpc and eliminate using  generic/specialize keywords?
@Martin_fr you are right, readability is mostly about familiarity. You know what Inc means, or you know when I say var, you know I mean variant. The point is stop at a general use case. For the rest, options and switches should be enough, that is why I am asking for it. If you write a little generic code, using generic/specialize is a nice note, but more of them and your code looks distracted as after a couple of hours you know what <> means.

[Martin_fr]

@Martin_fr you are right, readability is mostly about familiarity. You know what Inc means, or you know when I say var, you know I mean variant. The point is stop at a general use case. For the rest, options and switches should be enough, that is why I am asking for it. If you write a little generic code, using generic/specialize is a nice note, but more of them and your code looks distracted as after a couple of hours you know what <> means.

Yes (short time / temp), and no. The longer you hadn't looked at some code, before you return to it. You may still know what the "<>" mean, but you have to also spot them. Same with too many short vars. Code with i,j,k,l,m,n is easy to write at first... Come back later, and the story changes. If your code also uses lots of comparison, bitshift, enum >< / <> .... => then happy spotting of where you have specialization.

Instead, specialization should always be done outside code, and outside var blocks... For types, always declare a new named type for each specialization. Then you have space and room for the keyword.

The real problem is how generic functions work. Personally I consider it a huge flaw, that you can't (afaik) do something like

Code: Text  [Select][+][-]

1. procedure IntFoo = specialize GenFoo<Integer>;

(or even several overloaded "Foo").

But, if your issue is triggered by that, then  counter acting it with another flaw... Not a good choice imho. And leaving away the verbose "specialize" is a flaw. Remember one of the strength of Pascal is it verbosity. E.g. the begin end are much clearer, and easier to spot markers, than some curly brackets. And so "specialize" is a better marker than only "<>". Just, it doesn't belong into the actual code block. Pascal thrives on declaring stuff up front.

[Okoba]

I agree with your point about Pascal. declaring upfront is nice. But we are familar with () for functions, and to me <> is the same for generics.
Look at this code and see how it looks calm and easy to read.
I know it can be dangerous, sometimes, just like `with` block, but most of the times and in high level codes, it looks Pascalish to me.

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3.   {$mode delphi}
4.   {$modeswitch implicitfunctionspecialization}
5.  
6.   procedure Test<T>(var V: T);
7.   begin
8.     V += 1;
9.   end;
10.  
11. var
12.   V1: Integer;
13.   V2: QWord;
14. begin
15.   Test(V1);
16.   Test(V2);
17. end.            

[bytebites]

Same with other mode, see the difference.

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3.   {$mode objfpc}
4.   {$modeswitch implicitfunctionspecialization}
5.  
6.   generic procedure Test<T>(var V: T);
7.   begin
8.     V += 1;
9.   end;
10.  
11. var
12.   V1: Integer;
13.   V2: QWord;
14. begin
15.   Test(V1);
16.   Test(V2);
17. end.          
18.