I disagree here. Knowing the order of operations/evaluation is part of knowing
the language. If that’s the case it should be undefined (which forces a
rewrite) not chose a behavior that seems contrary to the documentation and
common practice in this area.
> On Jan 15, 2020, at 1:39 PM, Axel Wagner <axel.wagner...@googlemail.com>
> wrote:
>
>
> I don't think "clearly this behavior is not what you would want" is a valid
> generalization.
>
> type MyStruct{
> // …
> }
>
> func (x *MyStruct) initialize() error {
> // does some common verification and populates some internal data
> structures
> return nil
> }
>
> func New() (*MyStruct, error) {
> x := &MyStruct{
> // default fields
> }
> return x, x.initialize()
> }
>
> func NewWithFoo(f Foo) (*MyStruct, error) {
> x := &MyStruct{
> Foo: f,
> }
> return x, x.intialize()
> }
>
> You can say that you shouldn't do something like this, but it's IMO
> reasonable code to write and it expects different behavior.
>
> However, as per my previous e-mail, I would still prefer to rewrite this, of
> course :)
>
>
>> On Wed, Jan 15, 2020 at 8:33 PM Robert Engels <reng...@ix.netcom.com> wrote:
>> I think the way to look at it is “what would be the behavior of if you were
>> inline creating and initializing a struct containing both values” - clearly
>> this behavior is not what you would want or expect.
>>
>> > On Jan 15, 2020, at 1:25 PM, Paul Jolly <p...@myitcv.io> wrote:
>> >
>> >
>> >>
>> >> "when evaluating the operands of an expression, assignment, or return
>> >> statement, all function calls, method calls, and communication operations
>> >> are evaluated in lexical left-to-right order."
>> >
>> > My understanding goes as follows: the operands of the return statement
>> > are i and modify(&i). The comma after "return statement" in the above
>> > sentence is then important: because the only "function calls, method
>> > calls, and communication operations" in that list of operands are (is)
>> > modify(&i).
>> >
>> > Hence when i (as in the first operand) is evaluated is not specified.
>> > And therefore it's dangerous to rely on it being one value or another
>> > (which it could be given the example you provide).
>> >
>> > There was even some discussion at the London Gophers November 2019
>> > meetup (where the conundrum was very related
>> > https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1)
>> > about whether it would be possible to statically flag potential errors
>> > like this.
>> >
>> > --
>> > 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.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/9EC93CAE-B11C-45E3-9D01-AC4AE5769BEE%40ix.netcom.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1388A9A2-F321-459A-893E-6D90D42E7255%40ix.netcom.com.
