On Sat, Sep 18, 2021 at 9:20 PM cxr wrote:
>
> ```go
> // Generics definitions. Keyword interface also ok, generic better.
> generic MyGen(It, *St, ...) {
> // type assertions
> It.(type) int, MyInt // only one type no need
>
> // interface assertions
> St.(interface) io.Reader
> Neither. Return a blocking iterator, something like
>
> type Iterator struct {
> // Next blocks until a new message is available or the stream ends and
> returns if a new message is available.
> Next() bool
> // Message returns the current message. Must only be called after Next
>
On Sun, Sep 19, 2021 at 5:19 PM roger peppe wrote:
> In some ways, the existing API is arguably more ergonomic than the
> originally proposed generic version, as it's possible to use `errors.As` in
> a switch statement (eg to test several possible types of error) which isn't
> possible with the m
In some ways, the existing API is arguably more ergonomic than the
originally proposed generic version, as it's possible to use `errors.As` in
a switch statement (eg to test several possible types of error) which isn't
possible with the multi-return `As` variant.
A minor variant of the existing AP
On Sun, Sep 19, 2021 at 4:02 PM David Finkel wrote:
> You might be interested in the original draft proposal for errors.As:
>
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions
>
> In particular, it originally specified that errors.As would
You might be interested in the original draft proposal for errors.As:
https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions
In particular, it originally specified that errors.As would take a
type-parameter. (the version of generics that was propo
https://go2goplay.golang.org/p/S_RDDxhTI1a
In fact, it can infer the type parameter:
https://go2goplay.golang.org/p/rk7jyt3ob0v
I'm not sure how useful that is though, especially because "return" inside
that anonymous function will return from that anonymous function, not the
outer function.
ht
Hi, I want to translate the go tour to Arabic I have finished the first
page of the tour and I want to check if everything is good so when I want
to deploy the website to app engine, it's asking me for money and even when
I want to get 90 days free trial my credit card been rejected! (I think
becau
Brian Candler schrieb am Sonntag, 19. September 2021 um 13:38:49 UTC+2:
> Also, I may be missing the point, but does the following do what you want?
> https://play.golang.org/p/86DQD5QMbJ3
>
> _, err := os.Open("non-existing")
> if pe := (&os.PathError{}); errors.As(err, &pe) {
> fmt.Println("Fai
I make simple strings.Index using the z-algorithm (
*https://github.com/vl4deee11/zidx*). I agree with the opinion that this z
algorithm is not suitable for std/strings. Later I will try to optimize and
write tests and benchmarks, follow this repository if someone is
interested.
Thanks to every
Ah OK, so fmt uses Error() if it exists? Makes sense then, thanks.
BTW, I received additional (and badly-formatted) copies of your messages
from "n0jfr25eemnrtjzftkt4yna3zfn...@devo.memo.com", relayed via a
server 149.72.164.25 which appears to be sendgrid.com / joylabs.com. The
message itself
That's because the `Error` method is declared on the pointer, not the
value. So `fmt` uses its reflect-based printing for structs.
On Sun, Sep 19, 2021 at 1:44 PM Brian Candler wrote:
> However, the zero value itself is printable. It's only a pointer to the
> zero value which panics.
> https://
However, the zero value itself is printable. It's only a pointer to the
zero value which panics.
https://play.golang.org/p/LhmhdeHTb0m
On Sunday, 19 September 2021 at 12:34:40 UTC+1 axel.wa...@googlemail.com
wrote:
> I don't know if it's intentional, but I think it's expected. The panic
> hap
Also, I may be missing the point, but does the following do what you want?
https://play.golang.org/p/86DQD5QMbJ3
_, err := os.Open("non-existing")
if pe := (&os.PathError{}); errors.As(err, &pe) {
fmt.Println("Failed at path:", pe.Path)
}
On Sunday, 19 September 2021 at 12:24:13 UTC+1 Brian Candl
I don't know if it's intentional, but I think it's expected. The panic
happens because it tries to stringify the underlying error, which is nil. I
would say the creation of a packages error types are the purview of that
package. I don't think you can, generally, expect that their zero values
are va
Is this intentional?
https://play.golang.org/p/ylXlkOq2sID
Result I get in browser:
&{0}
%!v(PANIC=Error method: runtime error: invalid memory address or nil
pointer dereference)
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
I notice at least three things from your proposed syntax:
1. Passing a *type* as an argument ("os.PathError"), rather than a *value
of a type*
2. A control structure. This might involve passing a block of code as a
hidden argument (like blocks in Ruby), or some sort of macro expansion.
3. The s
I like the way error handling is done in the xerror package. Things become
more concise, but remain very easy to read and understand as in plain Go
errorhandling.
Here is the example of how to use xerror.As:
_, err := os.Open("non-existing")
if err != nil {
var pathError *os.PathEr
18 matches
Mail list logo
