implemented pad function

[aman-godara]

#394

Task:

• Implemented pad function
• add test cases
• document the function
• Elemental or Pure? -> Pure

[aman-godara]

While I was writing code I got ambiguous interface error to which I preferred to keep pad_with argument as non-optional (to support backward compatibility) over other possible solutions.

[ivan-pi]

Nice work @aman-godara!

Some comments:

• What happens when the pad_with dummy variable is of type(string_type) and the length is larger than 1? Wouldn't it be easier to limit pad_with to character(len=1) for now?
• In most cases I imagine padding will be performed with the whitespace character ' '. For such cases it is inconvenient to have to specify pad_with = ' '.

What I propose is to have the following versions (and analogous for padr):

    interface padl
        module procedure :: padl_string_default      ! whitespace
        module procedure :: padl_string_pad_with     ! caller provided padding symbol
        module procedure :: padl_char_default
        module procedure :: padl_char_pad_with
    end interface padl

If we decide to allow len(pad_with) > 1 in the future, I believe it remains possible to do it in a backward compatible way for both string_type and character. Even if we were to allow len(pad_with) > 1 I still believe most usage will be with character literals like pad_with = 'aabbcc'. The case where you would want to pass a variable of type(string_type) seems unlikely to me, but can be always added later if someone requests it.

So I guess my bottom line is that having pad_with of type(string_type) is not worth the implementation/maintenance effort at this early stage.

[aman-godara]

What happens when the pad_with dummy variable is of type(string_type) and the length is larger than 1? Wouldn't it be easier to limit pad_with to character(len=1) for now?

Yes, pad_with is limited to character(len=1) as of now. If a user gives pad_with as type(string_type) with length > 1, function will only consider first character for padding.
Also, when user gives "" (empty string) as pad_with padding is performed but with default " " (1 space).
[EDIT]: I think according to fortran standards having length of dummy argument > length of actual argument is not allowed. But still gfortran didn't give any error or warning.

I also liked the interface suggested by you let me make the changes.

---

Also, how about making the function elemental?
The only problem in doing so is that if a user gives an input like this:
padl(["abcde", "bcd", "abc"], 6, "#") output will be:
["#abcde", "#bcd ", "#abc "] which actually looks as if the input got its right side padded with " " (1 space) and left with "#".

Except this case in all other cases having an elemental pad function will be quite useful as length of outputs is any way going to be same for all the possible cases (including the one mentioned above) so there is no problem in returning the output.
OR
we can also keep padl_char_pad_with and padl_char_default as pure as of now, and make padl_string_pad_with and padl_string_default as elemental because they don't have any of these problems highlighted above and are quite useful if a user is interested in padding many strings at once.

[aman-godara]

I didn't consider the case where a user gives an array in output_length argument as such:
pad_with(["abc", "bcd"], [5, 6], '#')
where returning the output ["abc##", "bcd###"] in an array won't be possible.
I am keeping all functions as pure for now.

[awvwgk]

Only two minor comments, otherwise looks good to me.

[milancurcic]

Thank you @aman-godara, great addition, I left two comments.

[awvwgk]

Sorry for the merge conflict, I probably merged the PRs in the wrong order.