# \`move\_alloc()\` for the function result **URL:** \ **Category:** Uncategorized\ **Created:** [May 26, 2026, 12:22pm UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929 "2026-05-26T12:22:29Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [May 26, 2026, 12:22pm UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929/1 "2026-05-26T12:22:29Z")
Hello, Is it legal to pass the result variable of a function (which returns an allocatable variable) and use `move_alloc()` to move the function result to another allocatable variable ? Something like… ```fortran program main implicit none integer, allocatable :: a(:) call move_alloc(make_array(), a) contains function make_array() result(res) integer, allocatable :: res(:) allocate(res(3)) res = [1, 2, 3] end function end program ``` Is it also legal to move an allocatable component of a non-allocatable function result to another allocatable variable via `move_alloc()`…? If they are legal, is it OK to assume that only one allocation occurs in the `move_alloc()` statement (for the moved variable)? (By the way, AI automatically tries to modify my title by capitalizing `move` to `Move`… XD) ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [May 26, 2026, 1:35pm UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929/2 "2026-05-26T13:35:32Z")
In yout code, `make_array()` is an expression, which is not compatible with `intent(inout)`… And, from the point of view of an expression, the `allocatable` attribute is already lost. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [May 26, 2026, 2:48pm UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929/3 "2026-05-26T14:48:11Z")
Yes, that is exactly what I first thought (so I had never tried it with compilers before), but today I happened to ask the first paragraph in my post to both Gemini and ChatGPT (for curiosity). Then, both of them replied very confidently that “they are legal” and provided a sample code shown above. So, I just wanted to hear other people’s opinions. (FYI, I have just tried both gfortran and flang, and they just rejected the code.) The reply of Gemini is [here](https://gemini.google.com/share/ea2ac489082d). The confusion of AI may come from the scarcity of literature (particularly related corner cases). Overall, I guess asking Fortran questions to AI might need more caution (than e.g. Python) if they are related to not so common usage… (But otherwise, I really feel both the latest Gemini and ChatGPT are great, especially for literature summary (for Gemini) and math/physics discussions (ChatGPT). So the fields they are strong may vary…) ---
**Author:** ![simong](https://avatars.discourse-cdn.com/v4/letter/s/df788c/32.png) [@simong](https://fortran-lang.discourse.group/u/simong)\ **Post date:** [May 26, 2026, 4:26pm UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929/4 "2026-05-26T16:26:22Z")
I tried this example with Claude 4.7 and got > ● No, that’s not legal. > > move\_alloc(from, to) declares from as intent(inout) and requires it to be an allocatable variable. A function reference like > make\_array() is an expression, not a variable — even though the function result happens to be declared allocatable internally, what’s > passed to the caller is a value, and you can’t pass an expression to an intent(inout) dummy. > > The intended idiom here is just plain assignment, which since F2003 does automatic (re)allocation from an allocatable function result > with no copy needed in most implementations: > > a = make\_array() ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [May 26, 2026, 4:29pm UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929/5 "2026-05-26T16:29:04Z")
It’s not just a Fortran thing. LLMs in general are trained to give you a result, no matter what —and if the result happens to be a gateway for further prompting, then their goal is achievced. I have the tendency to ask for stuff in C-related terms, even if my actual intent is Fortran, and the results are not better —the one that stunned me the most was when ChatGPT’s output confidently included the `int66_t` type multiple times. Another funny thing is that, when confronted about the falsehood of their claims, LLMs tend to hallucinate lengthy and confusing explanations. My point is that LLMs are just assistants that can never be blindly trusted. YMMV. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [May 26, 2026, 4:38pm UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929/6 "2026-05-26T16:38:45Z")
Very interesting. I usually use LLMs for Python, and the results are very useful and time-saving for me (rather than digging various pages manually). But for rigorous purposes like checking syntax correctness (like above), it may be better not to trust it very much (unless we check the original literature shown by LLMs also). For the above case of Claude, I wonder it may have already utilized RAG, so reflecting the output here on the Discourse (that was my previous experience with ChatGPT or something, which almost immediately reflected the discussions on this Dicourse site). So, I guess the output depends on the timing we ask. For math/physics questions and discussions, on the other hand, I am very happy with its capability for step-by-step derivations etc, which are very helpful for learning new things (at least as a starter). Also, I have been using them extensively for literature search and survey, which I also feel very useful. On the other hand, for generating numerical codes or asking syntax correctness, I am still very cautious about them (so currently not using them for that purpose very much, unlike questions about various libraries in Python, installation or command usage, etc, etc). EDIT: When I further provided the output of flang and gfortran (compilation error) to both Gemini(3.5-Flash) and ChatGPT(5.5), both of them started to agree that the code is illegal. Interestingly, ChatGPT started to use the Thinking mode after I gave the compiler output and gathered a lot more pages and references. I then asked the same question using “temporary chats” for both LLMs, and they now give the correct answer in any case… (irrespective of Instant or Thinking mode). I will next try asking this kind of questions in the Thinking mode from the beginning (and also try Claude, which seems very nice for coding tasks.) ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [May 26, 2026, 8:13pm UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929/7 "2026-05-26T20:13:03Z")
As part of the training of those LLMs, they bend over backwards trying to agree with the prompter —Gemini not so much, but you can convince ChatGPT of pretty much anything. I remember that, as an experiment, I prompted that JSON was not a subset of YAML, simply because JSON came first. After a few round trips, ChatGPT started to agree with me, but Gemini never caved. So, I guess the issue can go both ways —we can convince some of them that some false stuff is true, and they (by virtue of Google giving Gemini the top spot in search results) can also propagate some convincing lies. ---
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [May 27, 2026, 10:12am UTC](https://fortran-lang.discourse.group/t/move-alloc-for-the-function-result/10929/8 "2026-05-27T10:12:54Z")
> 8.5.3 ALLOCATABLE attribute > > NOTE > Only variables and components can have the ALLOCATABLE attribute. The result of referencing a function whose result variable has the ALLOCATABLE attribute is a value that does not itself have the ALLOCATABLE attribute.