Great idea!
On Fri, Mar 15, 2019 at 11:25 AM zshi via golang-nuts <
golang-nuts@googlegroups.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?
>
>
> 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.
