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/CAEkBMfFf94%3DuKUqVfPeh0zGOYofeyHjfpuDSW9_Oik5p6ju9%2BQ%40mail.gmail.com.
