Sorry, they were posted in another similar thread:
https://groups.google.com/d/msg/golang-nuts/_sE6BxUDVBw/Rk02duq6CQAJ
https://groups.google.com/d/msg/golang-nuts/_sE6BxUDVBw/37-RUc-7CQAJ
> On Jul 4, 2019, at 3:45 PM, mh cbon <mhhc...@gmail.com> wrote:
>
> yes the zero value test seems akward from here also.
>
> It appears to me the proposal is sub optimal because,
> to put it clear, the operator is dumb.
> Its a disguised if with a one lin block statement.
>
> I believe it would gain a ton more usability by being smarter to allow for
> more useful predefined/expected
> behavior.
>
> this statements really looks like misformed
>
> on err, os.IsNotExist(err): <stmt>
> on err, err == io.EOF: <stmt>
> on err, err.(*os.PathError): <stmt>
>
> less stupid the oprator could infer various things based on static rules,
> very much like value/ptr initialization implies a few static rules.
>
> on os.IsNotExist(err): <stmt>
> on err == io.EOF: <stmt>
> on err.(*os.PathError): <stmt>
>
>
> On Thursday, July 4, 2019 at 5:14:40 PM UTC+2, Michael Ellis wrote:
> As noted by Aston, Jones, et al, the proposal is combining two ideas that are
> separable:
>
> Allowing one-liners. I like the idea of leaving that to gofmt. I'd be ok with
> requiring braces and allowing gofmt to make the decision to format in one
> line or three using some reasonable criterion.
> A test for not nil. In my view, saving a few keystrokes is not the reason to
> support such a test. I've already got an editor snippet that generates a
> default "if err != nil ... " clause. It just seems to me that "on err {
> doSomething }" is worth allocating a keyword for the (admittedly minor) gain
> in readability. Note: The actual proposal is more general than that. It
> defines 'on' as a test against the zero-value for the variable's type. I'm
> not sure that's a good idea. Seems messy if it were allowed to struct types.
>
>
> On Thursday, July 4, 2019 at 4:55:50 AM UTC-4, Slawomir Pryczek wrote:
> On one side, it's 1000x better than the other error handling specs, at least
> it isn't going to turn code into unreadable, fragmented mess. On the other,
> Aston seems to have a point, it's just replacing one-liner... and it's not
> that great at all because with "if" you know what it's doing without reading
> the spec.
>
> My point is it doesn't fix anything, it doesn't provide any clear benefit...
> it's an attempt to fix something which works great and is clearly not broken.
> So why complicate the language with a new keyword which has really no
> purpose. Maybe adding a warning about unhandled errors to VET would be better
> idea (which would probably be complicated to do properly, but at least it'll
> have some real, positive effect on code quality).
>
>
> W dniu wtorek, 2 lipca 2019 21:57:24 UTC+2 użytkownik Liam napisał:
> This proposal has attracted modest attention from the Go team...
> https://github.com/golang/go/issues/32611
> <https://github.com/golang/go/issues/32611>
>
> It suggests:
>
> err := f()
> on err, <single_statement>
>
> on err, return err // any type can be tested for non-zero
> on err, return fmt.Errorf(...)
>
> on err, fmt.Println(err) // doesn't stop the function
> on err, continue // retry in a loop
>
> on err, goto label // labeled handler invocation
> on err, hname // named handler invocation
>
>
> And offers these possible extensions:
>
> on err, os.IsNotExist(err): <stmt>
> on err, err == io.EOF: <stmt>
> on err, err.(*os.PathError): <stmt> // doesn't panic if not a match
>
> on err, <condition>: <stmt>
> on err: <stmt> // this pair provides if/else in 2 lines
>
> on err := f(), <stmt> // for assignment with single lvalue
>
>
> Other punctuation is possible, e.g. on (err) <stmt>
>
> Now if we could just convince the Go gods to prototype this along with try()
> in 1.14 :-)
>
> --
> 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
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8b5380ea-3fa8-4cc4-9094-545271c9467b%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/8b5380ea-3fa8-4cc4-9094-545271c9467b%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
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/B38A0FD4-DC72-4955-A274-80ED16F8A47E%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.
