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:
>
>
> 1. 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.
> 2. 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
>>>
>>> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/8b5380ea-3fa8-4cc4-9094-545271c9467b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
