Re: [go-nuts] obtaining the original type from a named alias type with go/types?

> That snippet is helpful, but given https://golang.org/issue/40965 I'm > concerned user defined aliases will suffer the same issue when it's > resolved. I would be very surprised if that affects Type() to be honest because that issue is about error message reporting, i.e. "unwinding" to actual

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

On Fri, 2020-08-21 at 21:51 -0700, Ian Lance Taylor wrote: > > > Thanks, Ian. > > > > No that doesn't work. For example with type byte, you get back the > > byte > > name. > > > > https://play.golang.org/p/PPjHBotsIsw > > The underlying type of byte is indeed byte. What are you hoping for? >

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

On Sat, 2020-08-22 at 06:00 +0100, Paul Jolly wrote: > I think you were unlucky with your choice of type to experiment with. > My understanding is that byte is special cased, despite being an > alias: > >

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

I think you were unlucky with your choice of type to experiment with. My understanding is that byte is special cased, despite being an alias: https://github.com/golang/go/blob/13e41bcde8c788224f4896503b56d42614e0bf97/src/go/types/universe.go#L25 Consider instead

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

On Fri, Aug 21, 2020, 9:16 PM 'Dan Kortschak' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Sat, 2020-08-15 at 21:44 -0700, Ian Lance Taylor wrote: > > On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts > > wrote: > > > > > > I would like to be able to obtain the

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

On Sat, 2020-08-15 at 21:44 -0700, Ian Lance Taylor wrote: > On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts > wrote: > > > > I would like to be able to obtain the original type for an alias > > given > > a source input. I can see in "go/types" that it's possible to know > >

Re: [go-nuts] Debug http calls made using go http client

I would use wire shark to inspect the traffic in more detail. > On Aug 21, 2020, at 1:59 PM, krishna...@gmail.com > wrote: > >  > Hello Gophers, > > I am making multiple http calls from my go application to an external > vendor's http server using the go standard http client. I've set a 10

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, Aug 21, 2020 at 3:03 PM Axel Wagner wrote: > > On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor wrote: >> >> Yes, there are various such possibilities. >> >> What jimmy frasche said above is correct: nothing changes in the case >> of a type switch of a type parameter. The code now

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 23:12, jimmy frasche wrote: > I don't want a generic min unless it looks like this: > > func Min[T constraints.Ordered](a, b T) T { > switch T { > case float32: > return T(math.Min(float32(a), float32(b))) > case float64: > return T(math.Min(float64(a),

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 23:03, Axel Wagner wrote: > On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor wrote: > >> Yes, there are various such possibilities. >> >> What jimmy frasche said above is correct: nothing changes in the case >> of a type switch of a type parameter. The code now knows

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 22:46, Ian Lance Taylor wrote: > Yes, there are various such possibilities. > > What jimmy frasche said above is correct: nothing changes in the case > of a type switch of a type parameter. The code now knows the type > list element that the type argument matched, but it

Re: [go-nuts] [ generics] Moving forward with the generics design draft

I don't want a generic min unless it looks like this: func Min[T constraints.Ordered](a, b T) T { switch T { case float32: return T(math.Min(float32(a), float32(b))) case float64: return T(math.Min(float64(a), float64(b))) } if a < b { return a } return b } On Fri, Aug

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor wrote: > Yes, there are various such possibilities. > > What jimmy frasche said above is correct: nothing changes in the case > of a type switch of a type parameter. The code now knows the type > list element that the type argument matched, but

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Aug 21, 2020, at 2:07 PM, roger peppe wrote: > > Here's one interesting implication of this: it allows us to do type > conversions that were not previously possible. > > For example, if we have "type I int", we can use a type switch to convert > some type []I to type []int: >

Re: [go-nuts] [ generics] Moving forward with the generics design draft

Yes, there are various such possibilities. What jimmy frasche said above is correct: nothing changes in the case of a type switch of a type parameter. The code now knows the type list element that the type argument matched, but it can't do anything that it couldn't do anyhow. Ian On Fri, Aug

Re: [go-nuts] [ generics] Moving forward with the generics design draft

also, of course, you could still use operators with them, while now also knowing the exact semantics of those operators (e.g. in regards to overflow), which might also be useful. On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner wrote: > > > On Fri, Aug 21, 2020 at 11:30 PM roger peppe wrote: > >>

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, Aug 21, 2020 at 11:30 PM roger peppe wrote: > On Fri, 21 Aug 2020 at 22:10, jimmy frasche > wrote: > >> I'd assume that would fail to compile as you're returning a []T not a >> []int >> > > If that's the case, then I'm not sure that such a type switch would be > very useful. It would

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 22:10, jimmy frasche wrote: > I'd assume that would fail to compile as you're returning a []T not a []int > If that's the case, then I'm not sure that such a type switch would be very useful. It would tell you what type the values are, but you can't do anything with them

Re: [go-nuts] [ generics] Moving forward with the generics design draft

I'd assume that would fail to compile as you're returning a []T not a []int On Fri, Aug 21, 2020 at 2:07 PM roger peppe wrote: > > > On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: >> >> After many discussions and reading many comments, we plan to move >> forward with some changes and

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the generics design > draft. > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going to

Re: [go-nuts] [ generics] Moving forward with the generics design draft

Hi all, A few people have raised concerns about "encouraging" use of any instead of interface{}, on the grounds that it is not idiomatic Go. I just wanted to acknowledge that yes, it's not idiomatic Go today, but that's true of essentially every language change. Thinking about future usage is a

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, Aug 21, 2020 at 1:30 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > My one concern with making it an alias is error messages. > If the source code says "any", I think so should the error messages. > Currently, the compiler forgets aliases too early >

Re: [go-nuts] [ generics] Moving forward with the generics design draft

I like all points in the draft change. My 2 cents around the any alias would be that it shouldn't be a problem. I don't think people are suddently going to start overusing it, since using vaues of type `interface{}` is extremely tedious in Go, and that won't magically change if the type is

Re: [go-nuts] Unique GO language features

On Fri, Aug 21, 2020 at 10:16 AM joseph.p...@gmail.com wrote: > > I really like the 'defer' statement and think it would be a useful addition > to other programming languages. I believe that Swift has also added a defer statement, which I assume was based on the idea in Go. > The feature where

[go-nuts] Debug http calls made using go http client

Hello Gophers, I am making multiple http calls from my go application to an external vendor's http server using the go standard http client. I've set a 10 second timeout for my context. Everything works fine. However, I get random timeouts in my application due to these HTTP calls. On

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, Aug 21, 2020 at 11:01 AM 'Carla Pfaff' via golang-nuts wrote: > > On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote: >> >> All constraints except "any" specify a constraint for the type. A >> Stringer constraint will ensure that the type has String() string >> method.

Re: [go-nuts] [ generics] Moving forward with the generics design draft

BTW, I am really glad your proposal is accepted, now the whole thing feels polished and IMO it is time to start building an implementation. пятница, 21 августа 2020 г. в 20:02:17 UTC+3, Carla Pfaff: > On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote: > >> All constraints

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 18:30, Axel Wagner wrote: > My one concern with making it an alias is error messages. > If the source code says "any", I think so should the error messages. > Currently, the compiler forgets aliases too early > . > I agree that's a

Re: [go-nuts] [ generics] Moving forward with the generics design draft

My one concern with making it an alias is error messages. If the source code says "any", I think so should the error messages. Currently, the compiler forgets aliases too early . On Fri, Aug 21, 2020 at 7:08 PM roger peppe wrote: > > > On Fri, 21 Aug 2020

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, Aug 21, 2020, 19:01 'Carla Pfaff' via golang-nuts < golang-nuts@googlegroups.com> wrote: People don't use the empty interface because they like it so much, but because Go doesn't have parametric polymorphism / "generics" yet. This argument seems to fail the fmt.Printf and friends

[go-nuts] Unique GO language features

I really like the 'defer' statement and think it would be a useful addition to other programming languages. The feature where GO performs escape analysis and promotes stack variables to the heap: Did that originate with GO or was it first implemented elsewhere? Thanks, Joe -- You received

Re: [go-nuts] Re: go test -timeout 30m can this be set inside Go code? disable timeouts programmatically?

Actually, that doesn't work. My apologies. If I figure it out, I will reply. On Fri, Aug 21, 2020 at 11:27 AM Mike P wrote: > I was able to accomplish this via the flag library in my testing function: > > flag.Set("test.timeout", "30m0s") > > ​ > > I found that being read from here: > >

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 15:24, Ian Lance Taylor wrote: > On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> Just to clarify, the intent is to make the declaration in the spec `type >> any = interface{}`, not `type any interface{}`, correct?

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote: > All constraints except "any" specify a constraint for the type. A > Stringer constraint will ensure that the type has String() string > method. "any" is a lack of constraint. The empty interface / any is a constraint that

[go-nuts] Re: go test -timeout 30m can this be set inside Go code? disable timeouts programmatically?

I was able to accomplish this via the flag library in my testing function: flag.Set("test.timeout", "30m0s") I found that being read from here: https://github.com/golang/go/blob/d21953df047868ed3bcfd0172a6c1672642f5b4a/src/cmd/go/testdata/script/test_timeout.txt#L22 So then I just changed the

Re: [go-nuts] [string] multiline stirng and break line "\n"

Hey, the `-quotes denote a "raw string literal". Escape-sequences in raw string literals are not interpreted - that's basically their purpose. So `t2` contains the literal two-byte sequence `\n`. You can see that in the output of `fmt.Println`, the newline is a 10, but t2 does not contain a 10,

Re: [go-nuts] [string] multiline stirng and break line "\n"

Variable t2 has no newline in its value. On Fri, Aug 21, 2020, 18:01 'Guilherme Dalmarco' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Why *bytes.IndexByte *can not find '\n' in multiline string? > > package main > > import ( > "bytes" > "fmt" > ) > > func main() { > t1 :=

[go-nuts] [string] multiline stirng and break line "\n"

Why *bytes.IndexByte *can not find '\n' in multiline string? package main import ( "bytes" "fmt" ) func main() { t1 := []byte("TEST\n") t2 := []byte(`TEST\n`) t3 := byte('\n') fmt.Println(t1) fmt.Println(t2) fmt.Println(t3) fmt.Println(bytes.IndexByte(t1, t3)) fmt.Println(bytes.IndexByte(t2,

[go-nuts] Re: [ generics] Moving forward with the generics design draft

I believe these are fantastic choices. I have given two presentations to Go meetups about the draft generics design in the last month. The second time was after the square bracket idea was added to the prototype and someone suggested the other parts adopted in item #1. In that second

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, Aug 21, 2020 at 7:43 AM 'Carla Pfaff' via golang-nuts wrote: > > On Friday, 21 August 2020 at 14:57:13 UTC+2 bbse...@gmail.com wrote: >> >> interface{}, when used as a constraint, doesn't mean than the value >> has to be an interface{}, it means the value can be anything. >> interface{},

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the generics design > draft. > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going to

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Thu, Aug 20, 2020, 11:22 PM Bakul Shah wrote: > On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor wrote: > > > 3. > > > > We’re going to clarify that when considering the operations permitted > > for a value whose type is a type parameter, we will ignore the methods > > of any types in the type

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Just to clarify, the intent is to make the declaration in the spec `type > any = interface{}`, not `type any interface{}`, correct? The latter would > be more analogous to `error`. Either has

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Friday, 21 August 2020 at 14:57:13 UTC+2 bbse...@gmail.com wrote: > interface{}, when used as a constraint, doesn't mean than the value > has to be an interface{}, it means the value can be anything. > interface{}, when used as a value, doesn't mean that the value can be > anything, it

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Thu, Aug 20, 2020 at 11:54 PM Kurtis Rader wrote: > > On Thu, Aug 20, 2020 at 10:40 PM burak serdar wrote: >> >> What worries me is code like this: >> >> func f() any { >>int *i >> return i >> } >> >> func main() { >>if f()==nil { >> ... >>} >> } >> >> Use of "any" makes it

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Aug 21, 2020, at 00:56, Ian Lance Taylor wrote: > > No, the intent is that you would switch on the type parameter itself, > not a value. > > func g[T C](v T) T { > switch T { >// the rest is the same > } > } > > Thanks for asking. Oh, this clarifies my remaining murkiness about the

Re: [go-nuts] [ generics] Moving forward with the generics design draft

Just to clarify, the intent is to make the declaration in the spec `type any = interface{}`, not `type any interface{}`, correct? The latter would be more analogous to `error`. Either has certain advantages and disadvantages, I'm not sure which I prefer, but I just want to make sure I understand

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor wrote: > > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the generics design > draft. > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Thu, Aug 20, 2020 at 10:53 PM Kurtis Rader wrote: > Isn't your example just a case of confusing a nil interface with a nil > value inside a generic interface? How does requiring writing it as `func > f() interface{} {` make the behavior any clearer? > And the, possibly canonical, discussion