Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > However, there is no way for P to check if x is nil. This does not compile: > > func P[T fmt.Stringer](x T) { > if x!=nil { > fmt.Println(x) > } > } Is this doing what you want? func P[T fmt.Stringer](x T) { if

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 10:37 PM Ian Lance Taylor wrote: > > On Tue, Jan 19, 2021 at 8:02 PM burak serdar wrote: > > > > On Tue, Jan 19, 2021 at 8:38 PM Ian Lance Taylor wrote: > > > > > > On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > > > > > > > > In the following program, it is valid

Re: [go-nuts] Interface arguments to generic functions

On Tue, 2021-01-19 at 21:38 -0800, Ian Lance Taylor wrote: > On Tue, Jan 19, 2021 at 8:41 PM Dan Kortschak > wrote: > > > > Would that work for non-comparable types? Say the T has an > > underlying > > []int type, then the comparison is not against nil and you end up > > with > > a panic. > >

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 8:41 PM Dan Kortschak wrote: > > On Tue, 2021-01-19 at 19:38 -0800, Ian Lance Taylor wrote: > > On Tue, Jan 19, 2021 at 7:06 PM burak serdar > > wrote: > > > > > > In the following program, it is valid to pass an interface to > > > function P: > > > > > > func P[T

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 8:02 PM burak serdar wrote: > > On Tue, Jan 19, 2021 at 8:38 PM Ian Lance Taylor wrote: > > > > On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > > > > > > In the following program, it is valid to pass an interface to function P: > > > > > > func P[T fmt.Stringer](x

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 8:38 PM Ian Lance Taylor wrote: > > On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > > > > In the following program, it is valid to pass an interface to function P: > > > > func P[T fmt.Stringer](x T) { > > fmt.Println(x) > > } > > > > func main() { > > var v

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > > In the following program, it is valid to pass an interface to function P: > > func P[T fmt.Stringer](x T) { > fmt.Println(x) > } > > func main() { > var v fmt.Stringer > P(v) > } > > However, there is no way for P to check if x is

Re: [go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.

On Tue, Jan 19, 2021 at 6:33 PM Wojciech S. Czarnecki wrote: > > I'd propose to amend specification so the type parameter identifiers were of > A-Z set, > ie. single uppercase ascii letter. While it is a current convention, it would > be better > to have this convention forced by compiler.

[go-nuts] Interface arguments to generic functions

In the following program, it is valid to pass an interface to function P: func P[T fmt.Stringer](x T) { fmt.Println(x) } func main() { var v fmt.Stringer P(v) } However, there is no way for P to check if x is nil. This does not compile: func P[T fmt.Stringer](x T) { if x!=nil {

[go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.

I'd propose to amend specification so the type parameter identifiers were of A-Z set, ie. single uppercase ascii letter. While it is a current convention, it would be better to have this convention forced by compiler. First to have an additional cue "generics here", second - to close an easy

Re: [go-nuts] How to get hold of GOARM at runtime?

You should also consider using x/sys/cpu to query the cpu features directly (not sure if that applies to your use case or not). On Tuesday, January 19, 2021 at 1:00:55 PM UTC-8 Ian Lance Taylor wrote: > On Tue, Jan 19, 2021 at 11:36 AM jan.f...@gmail.com > wrote: > > > > Short question:

Re: [go-nuts] `go list` across multiple modules?

On Tue, Jan 19, 2021 at 7:54 AM Jay Conrod wrote: > By the way, I'm not sure if you're already doing this, but if you can > batch all of the `go list` runs (or go/packages > .Load) together per module (passing an > argument per package), that will be much faster

Re: [go-nuts] `go list` across multiple modules?

On Tue, Jan 19, 2021 at 7:02 AM Jay Conrod wrote: > > > Interesting - is the difference the absolute paths vs relative? > > It looks like the bug has to do with whether the directory is below the main module root directory or not. If it is, the go command takes a path that assumes it's part of

Re: [go-nuts] package is not in goroot

On Tue, 2021-01-19 at 16:08 -0800, Alexander Mills wrote: > I have never seen the dot needed, I have used plenty of packages that > are in GOPATH but not GOROOT https://go.googlesource.com/go/+/go1.15.6/src/cmd/go/internal/search/search.go#542 This is why it is saying that it's expecting it to

[go-nuts] [security] Go 1.15.7 and Go 1.14.14 are released

Hello gophers, We have just released Go 1.15.7 and Go 1.14.14 to address recently reported security issues. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.15.7). - cmd/go: packages using cgo can cause arbitrary code execution at build

[go-nuts] Code Quality CLI Tool for Churn vs Complexity

Is there any code quality CLI tools for Churn vs Complexity? (which provides the same functionality as codeclimate service, but off-line, as a single command-line program - there are some nice tools like golangci-lint and gocyclo, but they do not provide this functionality) -- You received

Re: [go-nuts] Generics syntax suggestion

On Tue, Jan 19, 2021 at 11:45 PM Kevin Chadwick wrote: > On January 19, 2021 9:13:55 PM UTC, Levieux Michel > wrote: > >I think the question was: "given your proposal here, I can write func > >(string | []byte in1, string | []byte in2) which enforces that in1 and > >in2 > >must be either of

Re: [go-nuts] Generics syntax suggestion

On Tue, 2021-01-19 at 22:44 +, Kevin Chadwick wrote: > On January 19, 2021 9:13:55 PM UTC, Levieux Michel < > mlevieu...@gmail.com> wrote: > > I think the question was: "given your proposal here, I can write > > func > > (string | []byte in1, string | []byte in2) which enforces that in1 > >

Re: [go-nuts] Generics syntax suggestion

>>string >>or []byte) ? " >> > >You could always use a well placed &. That isn't the point.  Or perhaps group with {} like Darts optional parameters. Again though, not the point. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Generics syntax suggestion

On January 19, 2021 9:13:55 PM UTC, Levieux Michel wrote: >I think the question was: "given your proposal here, I can write func >(string | []byte in1, string | []byte in2) which enforces that in1 and >in2 >must be either of type string or type []byte, but how do I tell the >compiler that in1 and

Re: [go-nuts] package is not in goroot

On Tue, 2021-01-19 at 13:54 -0800, Alexander Mills wrote: > i am getting this weird error message: > > package twitch/go-scripts/dynamo-creators-to-s3/lib is not in GOROOT > (/usr/local/Cellar/go/1.15.6/libexec/src/twitch/go-scripts/dynamo- > creators-to-s3/lib) > > my GOPATH=$PWD/scripts/go >

[go-nuts] package is not in goroot

i am getting this weird error message: package twitch/go-scripts/dynamo-creators-to-s3/lib is not in GOROOT (/usr/local/Cellar/go/1.15.6/libexec/src/twitch/go-scripts/dynamo-creators-to-s3/lib) my GOPATH=$PWD/scripts/go so there is only 1 GOPATH [image: Screen Shot 2021-01-19 at 1.52.30

Re: [go-nuts] Generics syntax suggestion

On Tue, 2021-01-19 at 21:09 +, Kevin Chadwick wrote: > On January 19, 2021 8:22:01 PM UTC, 'Dan Kortschak' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > On Tue, 2021-01-19 at 20:01 +, Kevin Chadwick wrote: > > > I was inquiring about the possibility of no identifiers or > >

Re: [go-nuts] Generics syntax suggestion

I think the question was: "given your proposal here, I can write func (string | []byte in1, string | []byte in2) which enforces that in1 and in2 must be either of type string or type []byte, but how do I tell the compiler that in1 and in2 must be of the *same type* (whether it is string or []byte)

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On Tue, Jan 19, 2021 at 4:36 AM Kevin Chadwick wrote: > > On 1/19/21 12:21 PM, Axel Wagner wrote: > > And, of course, you can change the suggested syntax again. But every time > > you do > > a change like that, you are flushing the entire previous discussion down the > > drain, because we now

Re: [go-nuts] Generics syntax suggestion

On January 19, 2021 8:22:01 PM UTC, 'Dan Kortschak' via golang-nuts wrote: >On Tue, 2021-01-19 at 20:01 +, Kevin Chadwick wrote: >> I was inquiring about the possibility of no identifiers or >> abstraction but simply like Gos non generic functions (possibly >> reversed if needed). Using type

Re: [go-nuts] How to get hold of GOARM at runtime?

On Tue, Jan 19, 2021 at 11:36 AM jan.f...@gmail.com wrote: > > Short question: GOARCH and GOOS is available from the runtime package, but > how do I get hold of the corresponding variable GOARM at runtime? I don't think there is a way to fetch it directly, but you can see it by running "go env

Re: [go-nuts] Generics syntax suggestion

On Tue, 2021-01-19 at 20:01 +, Kevin Chadwick wrote: > I was inquiring about the possibility of no identifiers or > abstraction but simply like Gos non generic functions (possibly > reversed if needed). Using type OR type. > > func (String | []byte firstInput, myType | publicKey >

Re: [go-nuts] Generics syntax suggestion

How would you express the equivalent of func Min[T constraints.Ordered](a []T) T { min := a[0] for _, v := range a[1:] { if v < min { min = v } } return min } using this syntax? More generally, it is probably useful to go through the examples from the

[go-nuts] Generics syntax suggestion

>> Seems to me that most generics implementations use a capital letter >> abstracted type syntax that I hate. >> > >This is just a convention and not part of the syntax, which means it's >irrelevant to the discussion about the proposal. You can easily use >lowercase letters/identifiers:

[go-nuts] How to get hold of GOARM at runtime?

Hi, Short question: GOARCH and GOOS is available from the runtime package, but how do I get hold of the corresponding variable GOARM at runtime? Best Regards //Jan Flyborg -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On Tuesday, 19 January 2021 at 15:39:25 UTC+1 m8il...@gmail.com wrote: > Seems to me that most generics implementations use a capital letter > abstracted type syntax that I hate. > This is just a convention and not part of the syntax, which means it's irrelevant to the discussion about the

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

>Apologies then. I assumed you where trying to amend OPs suggestion, >which >was specifically to abscond with type parameters and the ability to >express >constraints. >Note the topic of this thread: »instead of generics, why cant we just >implement an "any" builtin?« Oops, Sorry for hijacking

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On Tue, Jan 19, 2021 at 6:08 PM Kevin Chadwick wrote: > I believe my suggestion included constraints in the function parameter list > whilst avoiding the needless abstraction? > Apologies then. I assumed you where trying to amend OPs suggestion, which was specifically to abscond with type

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On 1/19/21 4:53 PM, Axel Wagner wrote: > > Yes. And there are definitely syntactical choices that can be decoupled - like > how we went from `(type T)` to `[T any]`. Not having type parameters or ways > to > constrain them, though, is more than just a syntactical choice. It removes the > actual

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On Tue, Jan 19, 2021 at 5:16 PM Kevin Chadwick wrote: > On 1/19/21 3:32 PM, Axel Wagner wrote: > > > "I think this design sucks, you should throw it away and start from > scratch" > I assume you believe that is what I affectively said I think it is what OP has effectively said. The design is

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On 1/19/21 3:32 PM, Axel Wagner wrote: > "I think this design sucks, you should throw it away and start from scratch" I assume you believe that is what I affectively said but I am not sure if I were in a position of understanding all of the requirements and details, that I would agree? I gave a

Re: [go-nuts] `go list` across multiple modules?

By the way, I'm not sure if you're already doing this, but if you can batch all of the `go list` runs (or go/packages.Load) together per module (passing an argument per package), that will be much faster than loading individual packages with separate `go list` calls. It will save `go list` from

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

This is interesting, thanks! Is there a full description of the encoding somewhere? (e.g. how are structs represented? what about interface values, etc? is the schema implicit or sent on the wire?) cheers, rog. On Tue, 19 Jan 2021 at 14:59, Jonathan Amsterdam wrote: > Uses code generation

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On Tue, Jan 19, 2021 at 3:39 PM Kevin Chadwick wrote: > Sure, but the Go team needs to be realistic and realise that not everyone > is on > the salary that they are or can afford the time that they can, or even on a > consistent salary at all (e.g. founder with two jobs). People only having

Re: [go-nuts] `go list` across multiple modules?

> Interesting - is the difference the absolute paths vs relative? It looks like the bug has to do with whether the directory is below the main module root directory or not. If it is, the go command takes a path that assumes it's part of the main module, which it's not. > I hoped maybe `-modfile`

[go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

Uses code generation for fast encoding and decoding of Go values to bytes. Handles sharing and cycles too. https://pkg.go.dev/github.com/jba/codec -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On 1/19/21 1:41 PM, Axel Wagner wrote: > > OK, but using a T all over the place, sucks. > > > That is a fair opinion to hold. But if you don't like the current design and > want an alternative (or nothing at all) to happen, the strategy of just saying > "it sucks" just isn't going to be

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On Tue, Jan 19, 2021 at 1:36 PM Kevin Chadwick wrote: > On 1/19/21 12:21 PM, Axel Wagner wrote: > > And, of course, you can change the suggested syntax again. But every > time you do > > a change like that, you are flushing the entire previous discussion down > the > > drain, because we now have

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

He gave an idea and i found it *fun* to think of the implementation, i'm not proposing anything, in fact i wrote and deleted from my original text "This has probably been thought already", because it looked like i was proposing, and I'm not. On Tue, 19 Jan 2021, 09:21 'Axel Wagner' via

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On 1/19/21 12:21 PM, Axel Wagner wrote: > And, of course, you can change the suggested syntax again. But every time you > do > a change like that, you are flushing the entire previous discussion down the > drain, because we now have to re-consider all aspects of the design, from > tokenization,

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

Instead of giving one-off answers to one-off questions, I would suggest to write a detailed design doc, so we can talk about *that*. The design draft by Ian and Robert is the culmination of over a decade of thinking and talking about generics in Go and it goes to great lengths to shed light on all

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

Actually i thought it would be more complex than the current design, but a simpler api. I didn't know types could be created at runtime, this seems to scale up the problem by an order of magnitude. ps: sorry, forgot to hit "Reply all" On Tue, 19 Jan 2021, 08:44 Axel Wagner, wrote: > On Tue,

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On 1/19/21 11:43 AM, 'Axel Wagner' via golang-nuts wrote: > This is essentially the previous generics design > , > where you implicitly use the function body as a contract - with the exception, > that you have no way to

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On Tue, Jan 19, 2021 at 12:19 PM Artur Vianna wrote: > if you're trying to compare "a this as a operation necessary for that type to work, as an *implicit > contract*. And whenever this function is used, it checks this implicit > contract(s) with every type and fails to compile if it doesn't

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

On 1/19/21 11:19 AM, Artur Vianna wrote: > Similar how you can't compare two slices and it fails to compile, because > slices > aren't comparable. Internally the compiler would need the information on every > possible operation on every type, but i guess this partly exists already, as > part of

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

Not taking anyone's side here, but here's a example of how i think this "any" may work: if you're trying to compare "a wrote: > Hi, > > On Tue, Jan 19, 2021 at 6:47 AM mortdeus wrote: > >> The more I look at the proposed generic syntax the more I feel like a >> texan fearing the californian