Upon reflection I see that this is as you say. Not only expressed hazards,
but even such mysterious cases as file system modification yb external
scripts invoked by one argument and visible to another.
On Sat, Mar 16, 2019 at 10:03 PM T L <tapir....@gmail.com> wrote:
>
>
> On Friday, March 15, 2019 at 2:25:44 PM UTC-4, zs...@pinterest.com wrote:
>>
>> Thanks for response, I'm new here still need do more research on existing
>> topics.
>>
>> I understand compiler can do more optimization with less order
>> restriction, and I agree it's best to not coding in that way. The problem
>> is how to prevent people doing that since it's very similar to the usual
>> return multiple values style. Is it possible to add the check in golint,
>> such as when any comma separated expression (including return, assignment,
>> func parameters etc) contains variable who is also referenced in a func
>> closure (or get pointer in a func parameter) in the same expression, shows
>> a warning say the execution order is unspecified may cause bug?
>>
>
> It is possible for a linter to find some simple such cases. But it is hard
> to find some complicated cases.
> I ever wrote such a linter (not published). It only works for some simple
> cases.
> For my inexperience in using g0.* packages, the linter run very slow even
> for the simple cases.
> And I found that it is almost impossible to some complicated cases in
> theory.
>
>>
>>
>>
>> On Thursday, March 14, 2019 at 8:04:12 PM UTC-7, Ian Lance Taylor wrote:
>>
>>> On Thu, Mar 14, 2019 at 2:49 PM zshi via golang-nuts
>>> <golan...@googlegroups.com> wrote:
>>> >
>>> > I'm a little bit confused with result from below code:
>>> >
>>> > func change(v *int) bool {
>>> > *v = 3
>>> > return true
>>> > }
>>> >
>>> > func value(v int) int {
>>> > return v
>>> > }
>>> >
>>> > func main() {
>>> > b := 1
>>> > fmt.Println(b + 1, value(b + 1), change(&b))
>>> > }
>>> >
>>> > Output:
>>> >
>>> > 4 2 true
>>> >
>>> >
>>> > I expected 2 2 true. Then I checked spec, it said:
>>> > "all function calls, method calls, and communication operations
>>> are evaluated in lexical left-to-right order."
>>> > and:
>>> > "However, the order of those events compared to the evaluation and
>>> indexing of x and the evaluation of y is not specified."
>>> > So from that we can say both 4 2 and 2 2 are correct based on spec,
>>> although the implementation choose putting expression evaluated after all
>>> the function calls.
>>> >
>>> > I think it's better written into spec rather than say not specified.
>>> Why? because I already see some production code with below pattern:
>>> > .....
>>> > return b, change(&b)
>>> > }
>>> > (the real production code use a function closure which directly modify
>>> b without pointer, but I think the order issue is same)
>>> >
>>> > I don't know if this pattern is used a lot in other place since I'm
>>> still new to golang, but people writing go style probably like this way.
>>> Since it depends on a not specified behavior which has risk to change in
>>> future and very hard to debug, I think it's better written into spec which
>>> make sure it won't change in future.
>>> >
>>> > Any thoughts?
>>>
>>> This kind of discussion has been had several times, e.g.,
>>> https://golang.org/issue/23735. In general I don't think there has
>>> been a strong sentiment for precisely specifying evaluation order down
>>> to the level of exactly when the value of a variable is evaluated.
>>> The advantage of doing so is that code such as you describe becomes
>>> precisely specified. The disadvantage is that the compiler has much
>>> less scope for optimization.
>>>
>>> In general, code such as you describe is confusing and hard to read.
>>> It's impossible to recommend that people write code that way. And if
>>> we make that unclear code precisely specified, then the compiler will
>>> be forced to generate slower code even for clear code.
>>>
>>> So well there is an argument for fully specifying the code as you
>>> suggest, there is also an argument for leaving it unspecified.
>>>
>>> Ian
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
