FAQ
See this for an example of what I mean:

http://play.golang.org/p/ivgLHovmUr

Obviously gives compiler error:

prog.go:14: assignment count mismatch: 3 = 1

I liked this kind of style in Python, given that mulltiple assignments per
line are possible in Go (ie. x, y, z = 1, 2, 3), is there a syntactic
technique for the above?

--

Search Discussions

  • Minux at Oct 31, 2012 at 9:15 am

    On Wed, Oct 31, 2012 at 5:07 PM, Philipp Schumann wrote:

    See this for an example of what I mean:

    http://play.golang.org/p/ivgLHovmUr

    Obviously gives compiler error:

    prog.go:14: assignment count mismatch: 3 = 1

    I liked this kind of style in Python, given that mulltiple assignments per
    line are possible in Go (ie. x, y, z = 1, 2, 3), is there a syntactic
    technique for the above?
    your "func GetNStrings (count int) (vals []string)" doesn't return multiple
    return values,
    it returns only a single return value, which is a slice of string.

    --
  • Francisco Souza at Oct 31, 2012 at 9:23 am

    On Wed, Oct 31, 2012 at 7:07 AM, Philipp Schumann wrote:
    See this for an example of what I mean:

    http://play.golang.org/p/ivgLHovmUr

    Obviously gives compiler error:

    prog.go:14: assignment count mismatch: 3 = 1

    I liked this kind of style in Python, given that mulltiple assignments per
    line are possible in Go (ie. x, y, z = 1, 2, 3), is there a syntactic
    technique for the above?
    Not really. Go supports returning multiple values. If your function
    returns N values, then you have to assign these values to N variables
    (or ignore them).

    In your case, your function return one value, then you can assign it to
    one variable :)

    --
    ~f

    --
  • Job van der Zwan at Oct 31, 2012 at 9:37 am

    On Wednesday, 31 October 2012 10:07:42 UTC+1, Philipp Schumann wrote:
    See this for an example of what I mean:

    http://play.golang.org/p/ivgLHovmUr

    Obviously gives compiler error:

    prog.go:14: assignment count mismatch: 3 = 1

    I liked this kind of style in Python, given that mulltiple assignments per
    line are possible in Go (ie. x, y, z = 1, 2, 3), is there a syntactic
    technique for the above?

    As minux hinted at, what you're basically asking for is implicit type
    conversion, which Go simply does not do. Your function returns a slice,
    which can be of variable size, doesn't it make more sense if the program
    reflects this?

    http://play.golang.org/p/CrvH2cfkPV

    --
  • Stephen Day at Nov 1, 2012 at 7:00 am
    He's actually asking for destructing assignment, which is unsupported in Go.

    --
  • Job van der Zwan at Nov 1, 2012 at 7:42 am

    On Thursday, 1 November 2012 08:00:08 UTC+1, Stephen Day wrote:

    He's actually asking for destructing assignment, which is unsupported in
    Go.

    Do you mean destructuring assignment? I just googled "destructing
    assignment" and that's what it returned instead. In either case, I had
    never heard of the term before (so thanks for introducing me to it), but it
    looks to me that even if Go did support destructuring assigment, it
    shouldn't support it in this case: there's no way for the compiler to know
    what the length of the returned slice would be, so there's no way to guess
    if assigning to three variables is legal or not. Unless it would something
    like "just assign the first three values of the slice, and if the slice is
    smaller assign zero", which sounds like a horrible idea to me.

    --
  • Minux at Nov 1, 2012 at 7:52 am

    On Thu, Nov 1, 2012 at 3:42 PM, Job van der Zwan wrote:
    On Thursday, 1 November 2012 08:00:08 UTC+1, Stephen Day wrote:

    He's actually asking for destructing assignment, which is unsupported in
    Go.

    Do you mean destructuring assignment? I just googled "destructing
    assignment" and that's what it returned instead. In either case, I had
    never heard of the term before (so thanks for introducing me to it), but it
    looks to me that even if Go did support destructuring assigment, it
    shouldn't support it in this case: there's no way for the compiler to know
    what the length of the returned slice would be, so there's no way to guess
    if assigning to three variables is legal or not. Unless it would something
    like "just assign the first three values of the slice, and if the slice is
    smaller assign zero", which sounds like a horrible idea to me.
    right. if we had a tuple type, this destructuring assignment would be
    possible.

    --
  • Rory McGuire at Nov 1, 2012 at 9:04 am
    Hi minux,
    On Thursday, 1 November 2012 09:52:13 UTC+2, minux wrote:

    right. if we had a tuple type, this destructuring assignment would be
    possible.

    Are tuples being considered for Go?
    Have you seen any reason for Go to get Tuples?


    --
  • Minux at Nov 1, 2012 at 11:17 am

    On Thu, Nov 1, 2012 at 5:03 PM, Rory McGuire wrote:
    On Thursday, 1 November 2012 09:52:13 UTC+2, minux wrote:

    right. if we had a tuple type, this destructuring assignment would be
    possible.

    Are tuples being considered for Go?
    AFAIK, no.
    Have you seen any reason for Go to get Tuples?
    none (yet).

    --
  • Kevin Gillette at Nov 1, 2012 at 10:38 am
    Tuples are essentially just arrays... or structs... depending on what
    you're trying to do. If you consider something like python, where you can
    construct a tuple of any length at runtime, then tuples are like slices. In
    any case, Go already has all three work-alikes, and it seems it'd break the
    orthogonality thrice-ways if "tuples" were added.

    I don't see this "destructuring assignment" couldn't be done with slices,
    as something of the inverse of how variadics are handled. You extend `...`
    to be allowed in arbitrary single-valued expressions who's type happens to
    be a slice. In this case, line 14 of the original playground snippet would
    be changed to:

    var s1, s2, s3 = GetNStrings(3)...

    Behavior:

    1) if the returned slice, at runtime, has less than the desired number of
    elements, the remaining variables get a zero value.
    2) if the returned slice, at runtime, has less than the desired number of
    elements, panic.

    In the case of there being more elements than desired, we can be more
    flexibile:
    1) if there's a trailing blank variable, extra elements are ignored. ex:

    var s1, s2, s3, _ = GetNStrings(3)...

    2) if there's no trailing blank, and there are extra elements, panic.

    3) if there's a leading blank, it absorbs zero or more elements at the
    beginning of the slice, with variables being assigned in forward order on
    the tail of the slice.

    The compiler would detect expressions like the above, and do size checking
    as needed. When not used in an assignment, intermediates could be used,
    such as when filling a slice into a non-variadic (currently, slices can
    only be filled into variadics, of course).

    Anyway, since some behavior would necessarily have to be pushed into the
    runtime logic (though it's certainly doable with slices), either adding
    more spots for panics to occur, or for data to get "lost" (and thus
    comparatively impossible to debug), despite my believing it's doable, I
    don't really see the great benefit it would bring. Trying to pound a
    variable-length peg into a fixed-length hole _feels_ like it'll be the
    cause of many bugs, and will be abused by being used when the existing
    multi-value aspects of the language would have been an all-around cleaner
    solution.
    On Thursday, November 1, 2012 1:52:13 AM UTC-6, minux wrote:


    On Thu, Nov 1, 2012 at 3:42 PM, Job van der Zwan <j.l.van...@gmail.com<javascript:>
    wrote:
    On Thursday, 1 November 2012 08:00:08 UTC+1, Stephen Day wrote:

    He's actually asking for destructing assignment, which is unsupported in
    Go.

    Do you mean destructuring assignment? I just googled "destructing
    assignment" and that's what it returned instead. In either case, I had
    never heard of the term before (so thanks for introducing me to it), but it
    looks to me that even if Go did support destructuring assigment, it
    shouldn't support it in this case: there's no way for the compiler to know
    what the length of the returned slice would be, so there's no way to guess
    if assigning to three variables is legal or not. Unless it would something
    like "just assign the first three values of the slice, and if the slice is
    smaller assign zero", which sounds like a horrible idea to me.
    right. if we had a tuple type, this destructuring assignment would be
    possible.
    --
  • Peter at Nov 1, 2012 at 10:50 am
    I agree with Kevin. I can't see how I would need this feature (I haven't so
    far, anyway). How often do you return a variable number of arguments and
    don't want a slice? Why wouldn't you want a slice?
    On Thursday, 1 November 2012 10:38:20 UTC, Kevin Gillette wrote:

    Tuples are essentially just arrays... or structs... depending on what
    you're trying to do. If you consider something like python, where you can
    construct a tuple of any length at runtime, then tuples are like slices. In
    any case, Go already has all three work-alikes, and it seems it'd break the
    orthogonality thrice-ways if "tuples" were added.

    I don't see this "destructuring assignment" couldn't be done with slices,
    as something of the inverse of how variadics are handled. You extend `...`
    to be allowed in arbitrary single-valued expressions who's type happens to
    be a slice. In this case, line 14 of the original playground snippet would
    be changed to:

    var s1, s2, s3 = GetNStrings(3)...

    Behavior:

    1) if the returned slice, at runtime, has less than the desired number of
    elements, the remaining variables get a zero value.
    2) if the returned slice, at runtime, has less than the desired number of
    elements, panic.

    In the case of there being more elements than desired, we can be more
    flexibile:
    1) if there's a trailing blank variable, extra elements are ignored. ex:

    var s1, s2, s3, _ = GetNStrings(3)...

    2) if there's no trailing blank, and there are extra elements, panic.

    3) if there's a leading blank, it absorbs zero or more elements at the
    beginning of the slice, with variables being assigned in forward order on
    the tail of the slice.

    The compiler would detect expressions like the above, and do size checking
    as needed. When not used in an assignment, intermediates could be used,
    such as when filling a slice into a non-variadic (currently, slices can
    only be filled into variadics, of course).

    Anyway, since some behavior would necessarily have to be pushed into the
    runtime logic (though it's certainly doable with slices), either adding
    more spots for panics to occur, or for data to get "lost" (and thus
    comparatively impossible to debug), despite my believing it's doable, I
    don't really see the great benefit it would bring. Trying to pound a
    variable-length peg into a fixed-length hole _feels_ like it'll be the
    cause of many bugs, and will be abused by being used when the existing
    multi-value aspects of the language would have been an all-around cleaner
    solution.
    On Thursday, November 1, 2012 1:52:13 AM UTC-6, minux wrote:

    On Thu, Nov 1, 2012 at 3:42 PM, Job van der Zwan wrote:
    On Thursday, 1 November 2012 08:00:08 UTC+1, Stephen Day wrote:

    He's actually asking for destructing assignment, which is unsupported
    in Go.

    Do you mean destructuring assignment? I just googled "destructing
    assignment" and that's what it returned instead. In either case, I had
    never heard of the term before (so thanks for introducing me to it), but it
    looks to me that even if Go did support destructuring assigment, it
    shouldn't support it in this case: there's no way for the compiler to know
    what the length of the returned slice would be, so there's no way to guess
    if assigning to three variables is legal or not. Unless it would something
    like "just assign the first three values of the slice, and if the slice is
    smaller assign zero", which sounds like a horrible idea to me.
    right. if we had a tuple type, this destructuring assignment would be
    possible.
    --
  • Minux at Nov 1, 2012 at 11:19 am

    On Thu, Nov 1, 2012 at 6:50 PM, Peter wrote:

    I agree with Kevin. I can't see how I would need this feature (I haven't
    so far, anyway). How often do you return a variable number of arguments and
    don't want a slice? Why wouldn't you want a slice?
    tuples are useful because it can contain different types of objects (unlike
    strict typing
    arrays and slices).

    and i think the main usage for tuples is to compensate the lack of multiple
    return values.

    Go does have support for multiple return values, so i think one large use
    case of tuples
    is gone.

    --
  • Michael Jones at Nov 1, 2012 at 4:28 pm
    I would have used this in one of my programs. I converted a core
    recursion to a self managed combination of return stack and gotos for
    a 34% speedup. My stack has three variables that I need to restore
    before the goto on each "return." I tried many different ways of
    coding the push and the pop: as an array of structures with three
    values, as three arrays of values, etc. The performance in each case
    is limited by either the cost of the array bounds test (either one or
    three) or the cost of the packing and unpacking of the structure
    (three assignments or structure assignment of a struct literal. The
    three cases are:

    {
    sp := &exact.stack[k]
    columns = sp.columns
    c = sp.c
    r = sp.r
    }

    /*
    columns = exact.stack[k].columns
    c = exact.stack[k].c
    r = exact.stack[k].r
    */

    The uncommented version is the fastest by far. The braces are needed
    to help the compiler handle register pressure; the code is 2% slower
    without them. What I wanted was this:

    columns, c, r = destructure(exact.stack[k])

    which would let the compiler do one array bounds check, one index
    operation, and three direct moves. But I did not ask for it. I always
    seem to be asking for things that nobody else wants. For example, I
    would not put shaving a microsecond from the compile time above
    forcing programmers to try an exponential number of brace
    installations to manual show variable lifetimes. ;-)
    On Thu, Nov 1, 2012 at 4:19 AM, minux wrote:
    On Thu, Nov 1, 2012 at 6:50 PM, Peter wrote:

    I agree with Kevin. I can't see how I would need this feature (I haven't
    so far, anyway). How often do you return a variable number of arguments and
    don't want a slice? Why wouldn't you want a slice?
    tuples are useful because it can contain different types of objects (unlike
    strict typing
    arrays and slices).

    and i think the main usage for tuples is to compensate the lack of multiple
    return values.

    Go does have support for multiple return values, so i think one large use
    case of tuples
    is gone.

    --


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
  • Minux at Nov 1, 2012 at 4:42 pm

    On Fri, Nov 2, 2012 at 12:28 AM, Michael Jones wrote:

    I would have used this in one of my programs. I converted a core
    recursion to a self managed combination of return stack and gotos for
    a 34% speedup. My stack has three variables that I need to restore
    before the goto on each "return." I tried many different ways of
    coding the push and the pop: as an array of structures with three
    values, as three arrays of values, etc. The performance in each case
    is limited by either the cost of the array bounds test (either one or
    three) or the cost of the packing and unpacking of the structure
    (three assignments or structure assignment of a struct literal. The
    three cases are:

    {
    sp := &exact.stack[k]
    columns = sp.columns
    c = sp.c
    r = sp.r
    }

    /*
    columns = exact.stack[k].columns
    c = exact.stack[k].c
    r = exact.stack[k].r
    */

    The uncommented version is the fastest by far. The braces are needed
    to help the compiler handle register pressure; the code is 2% slower
    Thank you for sharing this great micro optimization trick.
    without them. What I wanted was this:

    columns, c, r = destructure(exact.stack[k])

    which would let the compiler do one array bounds check, one index
    operation, and three direct moves. But I did not ask for it. I always
    seem to be asking for things that nobody else wants. For example, I
    would not put shaving a microsecond from the compile time above
    forcing programmers to try an exponential number of brace
    installations to manual show variable lifetimes. ;-)
    Yeah, this is a reasonable and practical use case of destructuring
    assignment.

    However, i think that the manual sub-expression elimination also
    helps to reduce cognition load so it's fairly useful and i don't expect
    the compiler's help with this.
    IMO, the manual scoping to reduce registerization pressure is a work
    around, and i hope the compiler can handle this automatically in the
    future.

    Comparing:
    columns, c, r = destructure(exact.stack[k])
    and:
    sp := &exact.stack[k]
    columns, c, r = sp.columns, sp.c, sp.r

    I think the latter form is quite acceptable (no error when struct fields
    are reordered, thus adhere to the explicitness principle of Go)

    --
  • Michael Jones at Nov 1, 2012 at 4:50 pm

    On Thu, Nov 1, 2012 at 9:41 AM, minux wrote:

    Comparing:
    columns, c, r = destructure(exact.stack[k])
    and:
    sp := &exact.stack[k]
    columns, c, r = sp.columns, sp.c, sp.r

    I think the latter form is quite acceptable (no error when struct fields
    are reordered, thus adhere to the explicitness principle of Go)
    True, those are the advantages. Disadvantage is being "slower than
    optimal by design."

    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
  • Peter at Nov 1, 2012 at 4:54 pm
    Is it necessarily slower?

    A compiler could reasonably see that k is not changed and only do bounds
    checking once.

    Explicit and fast are both good Go principles :)
    On Thursday, 1 November 2012 16:51:10 UTC, Michael Jones wrote:

    On Thu, Nov 1, 2012 at 9:41 AM, minux <minu...@gmail.com <javascript:>>
    wrote:
    Comparing:
    columns, c, r = destructure(exact.stack[k])
    and:
    sp := &exact.stack[k]
    columns, c, r = sp.columns, sp.c, sp.r

    I think the latter form is quite acceptable (no error when struct fields
    are reordered, thus adhere to the explicitness principle of Go)
    True, those are the advantages. Disadvantage is being "slower than
    optimal by design."

    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>| +1
    650-335-5765
    --
  • Job van der Zwan at Nov 1, 2012 at 5:30 pm

    On Thursday, 1 November 2012 17:28:51 UTC+1, Michael Jones wrote:

    {
    sp := &exact.stack[k]
    columns = sp.columns
    c = sp.c
    r = sp.r
    }
    Wow, I never would have thought of doing something like that (including the
    manual scoping). Do you have a blog or a summary page where you collect
    micro-optimisations like this? Preferably with the reasoning that made you
    discover them in the first place? It seems to be kind of your thing.
    On Thursday, 1 November 2012 17:53:59 UTC+1, Peter wrote:

    Is it necessarily slower?

    A compiler could reasonably see that k is not changed and only do bounds
    checking once.

    Explicit and fast are both good Go principles :)
    Do any of the Go compilers do any optimisations that involve avoiding
    unnecessary bounds checking? And what do you consider reasonable? I
    wouldn't expect this to be optimised:

    columns = exact.stack[k].columns
    c = exact.stack[k].c
    r = exact.stack[k].r

    But this seems a bit more likely to me:

    columns, c, r = stack[k].columns, stack[k].c, stack[k].r

    ... since I think the evaluation of the left and right side could
    reasonably be micro-optimised.

    --
  • Minux at Nov 1, 2012 at 5:58 pm

    On Fri, Nov 2, 2012 at 1:30 AM, Job van der Zwan wrote:

    Do any of the Go compilers do any optimisations that involve avoiding
    unnecessary bounds checking? And what do you consider reasonable? I
    wouldn't expect this to be optimised:

    columns = exact.stack[k].columns
    c = exact.stack[k].c
    r = exact.stack[k].r

    But this seems a bit more likely to me:

    columns, c, r = stack[k].columns, stack[k].c, stack[k].r

    ... since I think the evaluation of the left and right side could
    reasonably be micro-optimised.
    Russ once said that he didn't like the idea of common sub-expression
    elimination in the gc compiler,
    and i tend to agree with that for this case, it's better to manually factor
    out the common parts, because
    it will make the intentions more clear.

    of course, it'd be nice to have the compiler avoid redundant bound checks
    in this case.

    --
  • Michael Jones at Nov 2, 2012 at 12:06 am
    comments inline...

    On Thu, Nov 1, 2012 at 10:30 AM, Job van der Zwan
    wrote:
    On Thursday, 1 November 2012 17:28:51 UTC+1, Michael Jones wrote:

    {

    sp := &exact.stack[k]
    columns = sp.columns
    c = sp.c
    r = sp.r
    }
    Wow, I never would have thought of doing something like that (including
    the manual scoping). Do you have a blog or a summary page where you collect
    micro-optimisations like this? Preferably with the reasoning that made you
    discover them in the first place? It seems to be kind of your thing.
    No. This is not something to "share" really as much as something to prod
    the compiler writers with to allow a little bit more of the goodness from
    IBM's Fortran-H compiler and the 50 years of research since into their
    work. I have a different philosophy about this than they do, but I'm not
    working on the compilers. ;-)

    I think that a compiler is the tool to help me squeeze every picosecond of
    needless expense. I have some research ideas of my own here but no agenda
    to push. I just value the whole spectrum from simple and concise on the
    human side of the tool chain to time and space efficiency on the machine
    side.

    The way I thought of the braces was to add the code above sans-braces and
    watch the performance drop by half, look at the generated code/profile, see
    that a dreaded stack split has fallen where I can't afford it, and then try
    to help the compiler realize shorter variable lifetimes with extra scoping
    crutches. I do not want people to do this! I want the compiler to traverse
    the expression tree BOTTOM UP and realize what can be reused. These are
    early days yet and the compilers should get much better.

    On Thursday, 1 November 2012 17:53:59 UTC+1, Peter wrote:

    Is it necessarily slower?

    A compiler could reasonably see that k is not changed and only do bounds
    checking once.

    Explicit and fast are both good Go principles :)
    Do any of the Go compilers do any optimisations that involve avoiding
    unnecessary bounds checking? And what do you consider reasonable? I
    wouldn't expect this to be optimised:

    columns = exact.stack[k].columns
    c = exact.stack[k].c
    r = exact.stack[k].r
    If I gave you...

    columns = exact.stack[k].columns
    c = exact.stack[k].c
    r = exact.stack[k].r

    ...and paid you to write it in assembler, I would expect you to compute the
    address of exact.stack once, exact.stack[k] once, and do a range-check
    once. If you did not, after representing yourself as a skilled coder with
    deep knowledge of the machine, I would fire you. That's how I think of
    compilers. They are the machine experts. They alone have the whole problem
    before them (the user's code, the code "inside" for loops and switch
    statements, the bounds checking code, the code for maps, etc.) They also
    have the result of developer code and generated code, such as from M4 or
    setter/getter automation. With all of this before them, and knowledge of
    the machine, and much more, they [well, it] are in the best position to
    know what is a common expression, what can be safely cached, what is less
    expensive to recompute, if x*2 or x<<1 is faster, and much more. I think
    this is the job.

    But this seems a bit more likely to me:

    columns, c, r = stack[k].columns, stack[k].c, stack[k].r

    ... since I think the evaluation of the left and right side could
    reasonably be micro-optimised
    Is not yet, but the future is limited only by vision.

    P.S. The compiler writers know how to do this. They are just being careful
    to keep all the code as clean and understandable as they can. Think "linux
    v1." Magic here can happen later. I'm just impatient.
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
  • Thomas Bushnell, BSG at Nov 2, 2012 at 7:51 am
    I expect gccgo will do the right thing here.
    On Nov 2, 2012 1:06 AM, "Michael Jones" wrote:

    comments inline...

    On Thu, Nov 1, 2012 at 10:30 AM, Job van der Zwan <
    j.l.vanderzwan@gmail.com> wrote:
    On Thursday, 1 November 2012 17:28:51 UTC+1, Michael Jones wrote:

    {

    sp := &exact.stack[k]
    columns = sp.columns
    c = sp.c
    r = sp.r
    }
    Wow, I never would have thought of doing something like that (including
    the manual scoping). Do you have a blog or a summary page where you collect
    micro-optimisations like this? Preferably with the reasoning that made you
    discover them in the first place? It seems to be kind of your thing.
    No. This is not something to "share" really as much as something to prod
    the compiler writers with to allow a little bit more of the goodness from
    IBM's Fortran-H compiler and the 50 years of research since into their
    work. I have a different philosophy about this than they do, but I'm not
    working on the compilers. ;-)

    I think that a compiler is the tool to help me squeeze every picosecond of
    needless expense. I have some research ideas of my own here but no agenda
    to push. I just value the whole spectrum from simple and concise on the
    human side of the tool chain to time and space efficiency on the machine
    side.

    The way I thought of the braces was to add the code above sans-braces and
    watch the performance drop by half, look at the generated code/profile, see
    that a dreaded stack split has fallen where I can't afford it, and then try
    to help the compiler realize shorter variable lifetimes with extra scoping
    crutches. I do not want people to do this! I want the compiler to traverse
    the expression tree BOTTOM UP and realize what can be reused. These are
    early days yet and the compilers should get much better.

    On Thursday, 1 November 2012 17:53:59 UTC+1, Peter wrote:

    Is it necessarily slower?

    A compiler could reasonably see that k is not changed and only do bounds
    checking once.

    Explicit and fast are both good Go principles :)
    Do any of the Go compilers do any optimisations that involve avoiding
    unnecessary bounds checking? And what do you consider reasonable? I
    wouldn't expect this to be optimised:

    columns = exact.stack[k].columns
    c = exact.stack[k].c
    r = exact.stack[k].r
    If I gave you...

    columns = exact.stack[k].columns
    c = exact.stack[k].c
    r = exact.stack[k].r

    ...and paid you to write it in assembler, I would expect you to compute
    the address of exact.stack once, exact.stack[k] once, and do a range-check
    once. If you did not, after representing yourself as a skilled coder with
    deep knowledge of the machine, I would fire you. That's how I think of
    compilers. They are the machine experts. They alone have the whole problem
    before them (the user's code, the code "inside" for loops and switch
    statements, the bounds checking code, the code for maps, etc.) They also
    have the result of developer code and generated code, such as from M4 or
    setter/getter automation. With all of this before them, and knowledge of
    the machine, and much more, they [well, it] are in the best position to
    know what is a common expression, what can be safely cached, what is less
    expensive to recompute, if x*2 or x<<1 is faster, and much more. I think
    this is the job.

    But this seems a bit more likely to me:

    columns, c, r = stack[k].columns, stack[k].c, stack[k].r

    ... since I think the evaluation of the left and right side could
    reasonably be micro-optimised
    Is not yet, but the future is limited only by vision.

    P.S. The compiler writers know how to do this. They are just being careful
    to keep all the code as clean and understandable as they can. Think "linux
    v1." Magic here can happen later. I'm just impatient.
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --

    --
  • Tomwilde at Nov 1, 2012 at 8:21 am
    Or make it possible only if the value to be destructed is an array (with a specific length).

    --
  • Stephen Day at Nov 2, 2012 at 2:08 am
    Yes, I meant "destructuring assignment". Typo.

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 31, '12 at 9:15a
activeNov 2, '12 at 7:51a
posts22
users11
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase