Passing Parameters: "inout" naming

[soraphis]

I'm somewhat confused about the use of the keyword: "inout". For me it makes no real sense, in terms of an analogy.

one could say "you pass the object in, and pipe your modifications out again", but that kinda contradicts the usage of "in" and "out", because there the analogy would rather be:

• "in" = "in only" = "not out" -> no modification on that object allowed.
• "out" = "not in" = "don't treat the argument as initialized"

so "inout" would be the exact opposite of what it is currently.

In C# we also have "in" and "out", but instead of "inout" there is "ref", which would also basically what "inout" is here. Another contestor for me would be "mut" (as in Rust) to show this argument is mutable.

but maybe it's only my analogy which is wrong, so if someone has a better for me, I'd be happy :)

[SebastianTroy]

I think of it less in terms of passing values and more in terms of the flow of side effects in the code On 21 August 2023 22:19:44 Soraphis ***@***.***> wrote: I'm somewhat confused about the use of the keyword: "inout". For me it makes no real sense, in terms of an analogy. one could say "you pass the object in, and pipe your modifications out again", but that kinda contradicts the usage of "in" and "out", because there the analogy would rather be: * "in" = "in only" = "not out" -> no modification on that object allowed. * "out" = "not in" = "don't treat the argument as initialized" so "inout" would be the exact opposite of what it is currently. In C# we also have "in" and "out", but instead of "inout" there is "ref", which would also basically what "inout" is here. Another contestor for me would be "mut" (as in Rust) to show this argument is mutable. but maybe it's only my analogy which is wrong, so if someone has a better for me, I'd be happy :) — Reply to this email directly, view it on GitHub<#610>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQJCDZPCSSNJT3ZULYTXWPGG3ANCNFSM6AAAAAA3Y6SW4M>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[soraphis]

I think of it less in terms of passing values and more in terms of the flow of side effects in the code

while this sounds super interesting, It sounds hard to me to map the names of "in"/"out"/"inout" to side-effects.

I can see "out". It's kinda like in C# where you also specify out on the caller side, denoting the side effect of "this is changed after this method call".

"in" does not really make sense in that way, though. It's merely just the opposite of out (naming wise) and means "side effect free" or if you'd call it a side effect: "the parameter has a value when going into the function".

while "inout" ... is definitely not "side effect free" ... I could see it "having a value going into the function" and "being changed after method call".

so, yeah. I guess that is a better analogy. thanks. (even though I still think, in that case "mut" would be a better fitting name.)

[jcanizales]

In my mind it maps to the flow of information: in - a value from outside is coming into the function; out - a value from inside the function is going out; inout both.

Then the fact that you can't modify an in argument is because you'd be sending information out by doing so. You can't read an out argument because you'd be bringing information in.

[JohelEGP]

You can't read an out argument because you'd be bringing information in.

Without first writing to it.

[jcanizales]

Yeah if you write something and then read what you wrote, you're not bringing any information from outside the function.

[SebastianTroy]

Fair enough, for what it is worth, I don't think of in as side effect free, I see it as side effects being passed to the function, ie the code in the function will respond differently to different in parameters, out means I cannot affect the function via that parameter, but it can effect the code on the callee side, so the side effects came out of the function, and inout is simply the combination of these two definitions. Move complicates it a little because it denotes the transfer of ownership of something, but it is also an in parameter in terms of side effects. On 21 August 2023 22:46:50 Soraphis ***@***.***> wrote: I think of it less in terms of passing values and more in terms of the flow of side effects in the code while this sounds super interesting, It sounds hard to me to map the names of "in"/"out"/"inout" to side-effects. I can see "out". It's kinda like in C# where you also specify out on the caller side, denoting the side effect of "this is changed after this method call". "in" does not really make sense in that way, though. It's merely just the opposite of out (naming wise) and means "side effect free" or if you'd call it a side effect: "the parameter has a value when going into the function". while "inout" ... is definitely not "side effect free" ... I could see it "having a value going into the function" and "being changed after method call". so, yeah. I guess that is a better analogy. thanks. (even though I still think, in that case "mut" would be a better fitting name.) — Reply to this email directly, view it on GitHub<#610 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQP3PSIDOHUVORTIM7TXWPJMRANCNFSM6AAAAAA3Y6SW4M>. You are receiving this because you commented.Message ID: ***@***.***>

[msadeqhe]

In languages such as C#, a property can have the following accessors:

• get: It doesn't have set operation. We cannot set its value.
• set: It doesn't have get operation. We cannot get its value.
• get set: It has both get and set operations. We can get and set its value.
• init, and other combinations.

Similarly in Cpp2, arguments can have the following behaviours:

• in: It doesn't have out operation. We cannot output a value.
• out: It doesn't have in operation. We cannot input a value.
• inout: It has both in and out operations. We can input and output a value.
• move, forward, etc.

[soraphis]

In languages such as C#, a property can have the following accessors:

but it's not rly about properties, but parameters instead. C# has in, out, ref. where ref feels imho more natural than inout (but thats personal preference)

[msadeqhe]

Yes, they are different, but the logic to name their keywords can be the same.

[SebastianTroy]

For what it is worth, for me in out inout is unambiguous, but get set getset is. in logically means the parameter is going into the function and changes will not come back out. Get means... The function is getting the parameter from the caller? The caller is getting the value constructed by the function? Both seem equally plausible to me. Same with set, is the parameter set by the function, or is the caller setting the value for the function? Now I know you've just said what they do mean, but when I come to remember it, my brain at least will struggle as it can plausibly imagine both scenarios On 11 September 2023 07:16:06 Sadeq ***@***.***> wrote: Yes, they are different, but the logic to name their keywords can be the same. — Reply to this email directly, view it on GitHub<#610 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQI7BFEW2MCBIBYNW4LXZ2UCHANCNFSM6AAAAAA3Y6SW4M>. You are receiving this because you commented.Message ID: ***@***.***>