Preface:
(This proposal started as an alternative solution to Ian Taylor's proposal "simplify error handling with || err suffix")

Proposal:

My proposal is to implement the conditional operator ('?') as an entirely new Go feature.

Rationale:

Before I start trying to explain what my proposal is, I want to take a moment to explain what my proposal isn't. This is not a proposal to implement a C style '?' operator in Go.

'expression ? expression : expression' // not this

Rather this is a proposal to try and integrate the ? operator into the language in such a way that "makes sense" in terms of Go's design.

Now, to explain what the Go ? operator does. The operator adds an element of conditionality to a built in statement. In other words, statements in code are read more like "questions". Should we return this? Should this Go routine run? etc.

In order to demonstrate what we are ultimately trying to solve here I first need to refer everyone to the warty issues we have when it comes to the way we currently deal with error handling, (particularly the issue of having to read and write the following code over and over again.)

x, err := foo() if err != nil { return err }

This sequence of code is so unnecessarily prevalent in Go code; that Ian Taylor's proposal's discussion thread has grown to a staggering 400 comments (and still appears to be rising without any signs of slowing down.),

And out of all those comments, all but a very minute few are complaints regarding the never ending repetition of boilerplate error handling. And from those complaints many counter proposals have materialized. Proposals such as making "error" even more magical using a '||' operator to write a magic one liner.

For example, the os.Chdir function is currently

func Chdir(dir string) error {
if e := syscall.Chdir(dir); e != nil {
return &PathError{"chdir", dir, e}
}
return nil
}
Under this proposal, it could be written as

func Chdir(dir string) error {
syscall.Chdir(dir) || &PathError{"chdir", dir, err} //<<<*
return nil
}
/* *note that the 'err' term being pointed out in the code above just magically exists, and consider the confusion that causes and how defining our return argument as func Chdir(dir string) (err error) doesn't make life any better. */

Other proposals are suggestions that have been proposed before and tend to have an element of feature overlap to them like the proposal to add try-throw-catch exception handling when we already have panic and recover.

Having read what most people had to say, I decided to chime in and give my two cents on Ian Taylor's proposal. Which is copy and pasted below.

Yeah, I propose that we just leave things the way they are. I was under the impression that Go's error system was deliberately designed this way to discourage developers from punting errors up the call stack. That errors are meant to be resolved where they occur, and to know when its more appropriate to use panic when you cant.

I mean isn't try-catch-throw essentially the same behavior of panic() and recover() anyways?

Sigh, if we are really going to start trying to go down this road. Why can't we just do something like

_, ? := foo()
x?, err? := bar()

or perhaps even something like

_, err := foo(); return err?
x, err := bar(); return x? || err?
x, y, err := baz(); return (x? && y?) || err?

where the ? becomes a shorthand alias for if var != nil{ return var }.

We can even define another special builtin interface that is satisfied by the method

func ?() bool //looks funky but avoids breakage.

that we can use to essentially override the default behavior of the new and improved conditional operator.

And now that I have caught everyone up on where we are right now and how we ultimately got here. We now get to move on to the more interesting bits of my proposal.

Design:

This proposal suggests to add to the language

• a new operator "?"
• a new builtin interface type
• a very special case overloaded switch statement OR a special method set that satisfies the above mentioned new builtin interface type.

Now, I realize this is very scary sounding and many of you are more than likely motioning your finger towards the backspace key right now. But I implore you all to hear me out.

First lets look at the syntax of the operator.

_, ? := foo()

This was my initial idea, that you can just assign to "?" as a way to say that if err != nil, you want to return the error to caller.

x?, err? := bar()

And this was taking the idea a step further. Here either x and/or err being != nil (should 0, "" == nil?) causes the function to assign new values to x, and err (in case were dealing with references) and then immediately return.

x, err? := bar()

And I just wanted to point out in this scenario, we only return when err != nil, when err == nil, x gets assigned to the new value and the program proceeds as normal.

Also I want to take a quick moment to point out that what I just described is not actually apart of the design im proposing. Rather its an entirely separate "mini" proposal, that can be used if we want to just get rid of the annoyingly repetitive "if err != nil {return err} code that is all over the place. And it also cleans up the syntax when you run into this wart

var err error if x, err = foo(); err != nil { return x, err }

with this proposal all that code gets condensed down to

x?, ? = foo();

Now I should point out that another key aspect of the ? operator in assignments is that it designates which variables are going to be sent back to the caller as return arguments.

For example x, ? = foo(); only sends back err if err != nil. x?, _ = foo(); only sends back x if x != nil (or 0, ""?), and last but not least x?, err? = foo() sends both back, in the event that either x or err != nil. It doesn't need to be both in that case.

Now, you might be asking, well what about when I have more or less return arguments than the function im returning from defines?

We can get around that a couple ways.

Assign identifiers to the return arguments and rely on a rule of a rightmost alignment when assigning to '?'.

For example

func foo() (msg Msg, len int, error){ defer func() int {? = msg.Len()} msg?, ? = fetchMsg() }

In this case every thing will line up properly because we are chaining the return args. However if you tried ?, ? = fetchMsg(), it should throw an invalid type error.

Or we can just use

Using ?, ??, ??? and ?n to manually indicate argument index from left to right. (or should it be right to left? and variadic assigns to same number?

func foo() (msg Msg, len int, error){ defer func() int {?? = msg.Len()} ?, ??? = fetchMsg()

And in the event that we have a ton of return args.

func foo() (msg Msg, len int, ts timestamp, error, error){ defer func() int {??,?5 = msg.Len()} ?, ???, ?4 = fetchMsg()

Anyways, as you can see, this "mini proposal" looses it's sex appeal completely when trying to use ? in many assignments and within defer.

Which is ultimately what led me to try to think of a completely different approach when thinking about this problem.

x, y, err := baz(); return (x? && y?) || err?

Here I show that instead of using ? in the assignment of variables, you use the ? to change a statement into what I essentially like to think of as the program asking permission.

_, err := foo(); return err?

The default behavior for the ? operator in this implementation is the same as before. We check to see if we aren't nil and if we aren't then we return. Otherwise we move on like normal.

x, err := bar(); return x? || err?
x, y, err := baz(); return (x? && y?) || err?

And you can use logical and/or (and the bitwise ops) to define the conditions that need to be satisfied for the return to execute.

x, y, err := baz(); return (x? && y?) || err?

Now when using a return statement like this, as before the ? designates which variables get sent back as return arguments and the alignment is left to right. It is assumed that everything after ? is regarded as a ',' until another ? is encountered and everything in between (including identifiers without a ?) is not relevant to an assignment.

I realize that this is a rather drastic change to the syntax of statements. Which is why I propose that we add another builtin interface.

The new interface which for now I just refer to as interface{?}, can be defined in two different ways.

The first way it can be defined is

type ? interface{ Go?() bool Return?() bool Select?() bool Switch?() bool For?() bool If?() bool Defer?() bool }

and then you can go about

type Foo int func (f Foo) Go?() bool { f.Foo() ok := Bar(f).Baz() return ok }

However, I don't think this is the best way, rather I would
create a magic switch case construct.

`

type ? interface{
?() bool
}

type Foo int
func (f Foo) ?() bool{
switch f? {
go?: // go specific code goes here
return?: // return specific code goes here
select?: // // select specific code goes here
switch?:// switch specific code goes here
for?: // for specific code goes here
if?: // if specific code goes here
defer?: // defer specific code goes here
}

foo()
bar(f).Baz()

// do more specific work after doing work that applies to all statements
switch f? {
go?: // go specific code goes here
return?: // return specific code goes here
select?: // // select specific code goes here
switch?:// switch specific code goes here
for?: // for specific code goes here
if?: // if specific code goes here
defer?: // defer specific code goes here
}
return true // or false
}`

And this way we can make super simple and easy to read calls like

`f, err := getTheFoo()

if f? && err? { // ? on builtins always defaults to nil/zero test.
return f, err
}else if err?{
return nil, err
}else{
return f?, nil
}`

which is a condensed form of

`f, err := getTheFoo()

if ifprep(f); f != nil && err != nil{
return f, err
} else if err != nil{
return nil, err
}else{
if f != nil {
returnprep(f)
return f, nil
}
}`

And that is basically what I propose.

This proposal is still very much a WIP and any feedback (positive or critical) would be greatly appreciated. Thanks!