In that proposal, some more syntax and semantics are being added - IMHO.
One problem here is the name of the error variable. Here we explicitly have
to used named return values - no new syntax there.
And return() and panic() on left side, only accept error type.
They will only be triggered when the error is not nil.
The concept is similar to piping functions - which Go already has a nice
form of it.
This approach is far more restricted and removes only the if someError !=
nil part. So there is much less room for "creativity".
*It enforces following early return technique/pattern*. Which leads to more
clear code.
For anything more complicated (in terms of conditions for handling the
error), we have to write the more complicated solution.
On Thursday, July 30, 2020 at 5:46:39 AM UTC+2 Ian Lance Taylor wrote:
> On Wed, Jul 29, 2020 at 7:46 AM Kaveh Shahbazian
> <kaveh.sh...@gmail.com> wrote:
> >
> > Go can already pass/pipe the result of a function, which returns
> multiple values, to another function, which accepts the same values as
> arguments. A similar mechanism can be used for handling errors, by
> passing/pipe them to a special construct.
> >
> > Now, assume we have a function named funcCtx:
> >
> > func funcCtx() (res int, err error) {
> > // ...
> > }
> >
> > Having that, these does not look that ugly:
> >
> > func funcCtx() (res int, err error) {
> > res, return() = action()
> > // or
> > res, panic() = action()
> > }
> >
> > Those statements will have an effect, only if the returned value is not
> nil. For performing some actions, before the actual return or panic:
> >
> > res, return({ log.Println(err) }) = action()
> >
> > There is this restriction, that the function that contains this block,
> funcCtx, has to return named return values - for both handling the zero
> values and having a one to one mapping between its return values and those
> of action function.
> >
> > Also for having a name, err in this case, that makes it clear, which
> variable we are talking about.
> >
> > In the proposal, it's not clear where the err variable comes from (what
> if there are three return values?)
>
> Thanks. This idea seems somewhat similar to https://golang.org/issue/27519
> .
>
> Ian
>
--
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/23f3c2e6-1f4e-4370-8212-5faaecb28c42n%40googlegroups.com.
