-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mutable arguments that are not meant to be returned #124
Comments
cc @AntoineSere who mentioned that problem to me. Did I describe the issue faithfully? |
Yes, the issue seems to me to be accurately described. |
Are there any good reasons to use this kind of pattern? It seems that the inline function could declare its own local stack variable instead of receiving it from the caller. |
If the same scratchpad can be used by different inlined functions, then this construct makes sense, as it allow you to only allocate one scratchpad instead of many if you were to declare a local stack variable in each inlined function. Here is a small modification of @eponier 's example illustrating this usecase:
In this example, only one scratchpad is needed. |
The compiler does that for you.
|
Apparently before PR #82, some people were relying on a pattern involving inline functions and
reg ptr
arguments used as a scratchpad. Here is a small example.Function
f
takes as an argument variablescratchpad
that is used to write temporary data and is useless after the function call, that's why it's not returned. This example used to work because:scratchpad
is not returned so is marked asconst
scratchpad[0] = 2;
during stack allocscratchpad
after the callWith PR #82, typing fails on
scratchpad[0] = 2;
since writing in aconst
array is now forbidden. Do we want this feature back? I don't think we want it back as is, because it was hacky. But one thing we could do is allowingreg mut ptr
not to be returned, meaning such a variable would be unusable after the function call. Maybe this would allow to reduce the lifetime of the variable because we wouldn't have to insert an assignment after the function call. And it could be supported also for non-inline functions.The text was updated successfully, but these errors were encountered: