implemented move_alloc for string_type

[aman-godara]

Closes #449

Tasks:

• Implemented move
• added test cases for move
• documented newly created function
• Pure vs Elemental?
• Name of the function?: as of now it is named as move
• move if both arguments are of type character(len=:)?: move_alloc does the same thing OR should we consider renaming it from move to move_alloc.

[awvwgk]

Pure vs Elemental?

It can't be elemental since it might handle an allocatable data type in case of deferred length characters. You could swap two string_type arrays with an elemental subroutine, though. Not sure if this is a common application of this procedure.

move if both arguments are of type character(len=:)?: move_alloc does the same thing OR should we consider renaming it from move to move_alloc.

It can't overload move_alloc since we won't be able to use the procedure in the context of type(string_type), allocatable anymore, like in the example below:

use stdlib_string_type
type(string_type), allocatable :: str1, str2
str1 = string_type("Moveable string value")
call move_alloc(str1, str2)
end

[awvwgk]

This is a useful addition, thanks.

[aman-godara]

Requesting Clarification:

As I understand, the function can't be made elemental because a user cannot create an array in which each element is of type character(len=:), allocatable? Have I understood it correctly?

[aman-godara]

How about instead of overloading the move_alloc we provide the functionality of move_alloc (for character allocatable) in move as well. To do this we will just call move_alloc inside move and that will do the job.

character(len=:), allocatable :: char_1, char_2
char_1 = "moveable char"
move(char_1, char_2)         ! char_2 <-- "moveable char"
move_alloc(char_2, char_1)   ! char_1 <-- "moveable char"

above expected behaviour can be carried out using move_alloc as well. Thus, both move_alloc and move can do this.

[aman-godara]

@awvwgk I have added a commit 73ec8c5 corresponding to comment mentioned just above by me.

I added move for both arguments as character allocatable (character(len=:), allocatable) so that a user need not to use a boilerplate if-else condition before using move to use move_alloc if both arguments are character allocatable.
If there are no repercussions, then in my opinion this will be good to have. Let me know your thoughts on this.

[zoziha]

move_alloc requires its arguments to be allocatable.
The move function arguments here are type(string_type), which is not allocatable.
If we overload move_alloc, it may cause users to misunderstand that move_alloc is different from the Fortran standard at allocatable attribute .
From this perspective, I think the name can be move or move_alloc_, better not move_alloc?

But from the perspective of actual use and as an extended function, I think move_alloc is also good.

[aman-godara]

I found move to be intuitive as well. As if it cut and pastes (not exactly) a string from one location to other. Similar to moving a file from one folder to other.

[milancurcic]

Very nice, thanks @aman-godara. We'll merge it tomorrow if there are no objections.

[aman-godara]

But wait! I have objections here. Have a look at commit 73ec8c5 once. I will also improve test cases and documentation for this.

[aman-godara]

Requesting Clarification:

As I understand, the function can't be made elemental because a user cannot create an array in which each element is of type character(len=:), allocatable? Have I understood it correctly?

Did I understand it correctly?

---

I have made all the change that I wanted to make. PR is open to be merged from my side. I found the behaviour of the last test case non-intuitive but I think we cannot do anything with it.

[milancurcic]

@aman-godara correct, the dummy argument can't be allocatable in an elemental procedure.

I also don't see a use case for the last test, but I can't tell that it hurts to leave it there.

Let's merge tomorrow if no objections. Thanks again!