On Tue, Mar 21, 2017 at 10:38 AM, Paul Jolly wrote:
>> The problem was that I repeatedly mentally misread 'indexing' for 'index
>> evaluation'. As the index is a constant in this case, it lead me to believe
>> it cannot have any effect on the result. But it's the 'indexing',
>
> The problem was that I repeatedly mentally misread 'indexing' for 'index
> evaluation'. As the index is a constant in this case, it lead me to believe
> it cannot have any effect on the result. But it's the 'indexing', the
> actual time when the value is loaded using the index, which is exempt
On Tue, Mar 21, 2017 at 6:11 PM John McKown
wrote:
> Logically yes, but due the implementation, along with "side effects"
(undocumented?), it does. The "x[0]|=foo()" moves x[0] to a temporary area.
It then invokes foo(). It then does the logical or from the
On Sun, Mar 19, 2017 at 6:20 PM, Steven Hartland
wrote:
> Think the following section should explain the strange behaviour you're
> seeing:
> https://golang.org/ref/spec#Order_of_evaluation
>
> On 19/03/2017 22:59, Jan Mercl wrote:
>
> While trying to resolve a failing
Think the following section should explain the strange behaviour you're
seeing:
https://golang.org/ref/spec#Order_of_evaluation
On 19/03/2017 22:59, Jan Mercl wrote:
While trying to resolve a failing (C) test case[0] I encountered a
(Go) behavior I do not understand. This code[1]
While trying to resolve a failing (C) test case[0] I encountered a (Go)
behavior I do not understand. This code[1]
package main
import (
"fmt"
)
var (
x = [1]int{2}
x2 = [1]int{2}
)
func foo() int