On Tue, Jan 30, 2018 at 7:20 PM, Dmitriy Cherchenko <dcherche...@gmail.com> wrote:
> The second possibility you described is exactly what I’m worried about. > But I have several places where I’m doing something like b.data[b.grow()] = > bt and wouldn’t want to break that up into two lines everywhere. I was > wondering if you could find anything else in the spec to guarantee that the > index (b.grow()) is evaluated first, before the slice is identified. > I don't think right now you can (though, TBH, I'm not great at rules-lawyering prose). I'm not saying you shouldn't be (i.e. I'm not saying that specifying this wouldn't be a good thing to do), just that with the spec as it is, this is not specified and you have to decide whether to trust that implementations behave as expected (and leave it in one line) or want to be safe and split it up in two. I think the code you posted is completely reasonable code and it is completely reasonable to expect it to behave as you intend - which is why I think the spec should somehow be amended to make it work that way (otherwise it would make it far too easy for a bug to sneak through code review). But until then, the spec is as it is. You might want to add this example to the bug Ian linked (or one of the related ones linked from there). -- 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.
