proposal: Go 2: Allow multiple check for `if` operator with assignment

[pmpavl]

In the language, very often there are nested constructions consisting of the if operator. Because of this, there is a great cyclomatic complexity. Consider a two struct and one of them has a Validate() method:

type Example struct {
    Child *ExampleChild
    // ...
}

type ExampleChild struct {}

func (e ExampleChild) Validate() error {
    // ...
}

let's say, we want to write a validation method for the entire Example structure. Then, in the current syntax of the language, we need to first check that Child != nil, and only then call the validation method for Child:

func (e Example) Validate() error {
    // previous checks

    if e.Child != nil {
        if err := e.Child.Validate(); err != nil {
            // ...
	}
    }

    // another checks
}

Of course, we can check in the first if that Child == nil, but then we will have to terminate the function after executing the part responsible for Child != nil. But let's say there is more than one such pointer field, then there is no way to get rid of the nesting of if. We will have to put validation of fields inside the non-nil checking.

My suggestion is to allow the syntax to write constructions of this type:

func (e Example) Validate() error {
    // previous checks

    if e.Child != nil && err := e.Child.Validate(); err != nil {
        // ...
    }

    // another checks
}

[ianlancetaylor]

What is the exact syntax that you are proposing? Because to me it seems that the new syntax got permit quite complex code in a different way.

To put it another way, to some extent cyclomatic complexity is a characteristic of the problem being solved, not of the program being used to solve it. It seems that this proposal just shifts that around syntactically. An && in an expression is just a hidden if.

[pmpavl]

What is the exact syntax that you are proposing?

I mean, why not allow multiple assignment between conditional operator. Today it is possible to make an assignment inside a logical operation, but it cannot be combined with others, and it inflates the code.

Therefore, I suggest syntax sugar for expressions like if expression1 { if expression2 { }}, where expression is an assignment condition like in example err := e.Child.Validate(); err != nil.

In general, I propose to legalize expression with assignment along with the usual logical constructions.

This will allow, as in the example, to first check that the pointer is not nil and then, if not nil, perform Validate(). This is a regular if-if, of course, but in one line, more pretty. I give this example because there are very often such if-if cases in the code that it seems (since the Go already has expression with assignment) could be made more elegant.