Multiple Assignment with one declared, one undeclared variable #959
-
Hey there, I was coding some stuff with Odin and I am currently facing this "problem" (not sure if it is by design or not). So imagine you have procedures
The compiler will complain since the call to procedure Is there going to be support to declaring only some variables in a multiple return values procedure call? I know this can be fixed by just declaring all variables earlier, but since Odin does a good job at reducing LOC this could further help reducing it. Cheers, example code, not code from actual situation |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
I'm under the impression that something like that would serve to complicate
the language more than it needs to be.
For my code, when I run into that, I just forward declare the variables,
then use the assignment operator. It works out fine and isn't really any
more complex.
…On Mar 8, 2017 4:10 PM, "ruipsrosario" ***@***.***> wrote:
Hey there,
I was coding some stuff with Odin and I am currently facing this "problem"
(don't know if it is by design or not).
So imagine you have procedures A and B which both return (AType, string)
and (AnotherType, string), respectively. And you have this snippet of
code:
aType, errorString := A();
anotherType, errorString := B();
The compiler will complain since the call to function B will attempt to
redeclare errorString. However, the intent was to reuse errorString from
the declaration of calling A and declare anotherType. Due to using := the
compiler will interpret as declaring *both* variables. Using = the
compiler will complain anotherType isn't defined.
*Is there going to be support to declaring only some variables in a
multiple return values procedure call?* I know this can be fixed by just
declaring all variables earlier, but since Odin does a good job at reducing
LOC this could further reduce it.
*example code, not code from actual situation*
Cheers,
Rui Rosário
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#29>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AM_tFCCcmaFWRCkIzQk5BwhLciBNODLJks5rjyc9gaJpZM4MXYAx>
.
|
Beta Was this translation helpful? Give feedback.
-
@zangent I don't mind forward declaring variables (I'm already used to that), I was just curious if it was something that was planned but overlooked or just something that was ignored by design. |
Beta Was this translation helpful? Give feedback.
-
TL;DR This is by design and not a mistake.
If you do have a "tuple" value on the right hand side, you either have to predeclare all the variables or remove the type (or specify the type if they are all of the same type). Tuples are not a first class type in this language and this is by design. I've found that tuples are only ever useful as return values from procedures and a named membered record is a much better thing to have (even if it is a little more verbose). In Go, I hope this clears things up. You can still use |
Beta Was this translation helpful? Give feedback.
TL;DR This is by design and not a mistake.
:=
Is actually: =
with the type missing. So what you are doing is double declaration that variable.If you do have a "tuple" value on the right hand side, you either have to predeclare all the variables or remove the type (or specify the type if they are all of the same type). Tuples are not a first class type in this language and this is by design. I've found that tuples are only ever useful as return values from procedures and a named membered record is a much better thing to have (even if it is a little more verbose).
In Go,
:=
is called a short variable decl…