[J3] [EXTERNAL] Re: Limitations of SELECT RANK?

[Clune, Thomas L. (GSFC-6101)]

Jon,

The compiler is going to have to replicate the block either way.   One way just requires more characters on the part of the programmer.   No one is asking for magic under the hood.

The values for RANK selector’s are already required to be constant, and we are not suggesting that it change.  Rather we are just asking for more compact notation (or arguments as to why this is a bad approach compared to template parameters, as per the response to Bill.)      Just as with SELECT CASE, we would expect the user to either provide a list of const values for rank, e.g, RANK(1,2,7), or a range  RANK(1:3).   

- Tom



> On Oct 20, 2020, at 12:21 PM, Steidel, Jon L <jon.l.steidel at intel.com> wrote:
> 
> Tom wrote:
> We are seeing that common use cases for SELECT RANK have duplicate text.      Aside from generic resolution, there are also cases involving whole array arithmetic.   For these cases,  the shorthand in my example is not just convenient for the coder, but is also a means to reduce errors that can happen when a subsequent change is only propagated to a subset of the RANK clauses.   Granted, this is the weakest case of code duplication, as the duplicates would all line up next to each other in a single file.
> End Tom
> 
> While there may be use cases that have duplicate text in multiple SELECT RANK case blocks, many involving whole array arithmetic, the code generated for each of the blocks is very different due to the difference in the array ranks between the two blocks.  The compiler would have to replicate the block for each possible rank and generate a separate block for each rank.  The ranks specified in the rank selector would need to be constant for this to happen, they could not be variable or values evaluated at runtime.
> 
> -jon
> 
>