Re: [go-nuts] Re: Go 1.18 Beta 1 is released

On Thu, Dec 16, 2021 at 4:01 AM Jan Mercl <0xj...@gmail.com> wrote: > > On Tue, Dec 14, 2021 at 8:51 PM Cherry Mui wrote: > > Let me report another failure that works, ie. tests build and pass, > with Go1.17.5 but not with Go1.18beta1 > > > jnml@darwin-m1:~$ GO111MODULE=off go get

Re: [go-nuts] Threats found on Win 10 21H1 64 bit computer

On Thu, Dec 16, 2021 at 3:18 PM Robert Solomon wrote: > > Since this is Windows Defender, the bug report would have to go to Microsoft. > I've heard that they largely ignore such reports. > So it goes. Microsoft is a pretty big user of Go, so they might not ignore this particular report. Ian

Re: [go-nuts] Threats found on Win 10 21H1 64 bit computer

Since this is Windows Defender, the bug report would have to go to Microsoft. I've heard that they largely ignore such reports. So it goes. Thanks for answering me, though. --rob solomon On Wednesday, December 15, 2021 at 9:13:12 PM UTC-5 Ian Lance Taylor wrote: > On Wed, Dec 15, 2021 at

[go-nuts] Re: generics: Zero value for any type parameter

torsdag 16 december 2021 kl. 23:40:09 UTC+1 skrev Johan Bolmsjö: > > My workaround has been to create a dummy variable, zeroValue in the > following example. I'm wondering if this is how to solve this problem or if > there is a better way. > > I realized I should have read the generics

[go-nuts] generics: Zero value for any type parameter

Hello, I've been playing with the new generics support in 1.18beta 1 today. I've come across a situation a couple of times where it would be convenient to be able to conjure the zero value for a variable corresponding to a type parameter. I've searched a bit for this to no avail.

Re: [go-nuts] Help with GOLLVM

Greetings, The code that Go compilers emit is closely tied to the Go runtime-- any compiled Go code (including *.ll files) will have references to symbols that it needs from the runtime. When you try to convert your LLVM-produced bitcode into a binary via clang helloworld.ll -o helloworldLLVM

[go-nuts] Re: generics: what can we do with an any type?

The code you wrote is using a generic value, but it is not itself generic. There is only one instantiated version of the runInt() function, and it knows (at compile-time!) that mySet is an map[int]int. Make that function actually generic - something like: func testThing[K comparable, V any](m

[go-nuts] Re: generics: what can we do with an any type?

[]byte is a no comparable type. quoting the docs: *comparable is an interface that is implemented by all comparable types(booleans, numbers, strings, pointers, channels, interfaces,arrays of comparable types, structs whose fields are all comparable types).The comparable interface may only

[go-nuts] Re: Java to Golang converter

The topic is very interesting, is anyone being worked on a subject ? Thank you. четверг, 11 мая 2017 г. в 21:19:13 UTC+3, dtr...@gmail.com: > > Java has vast number of libraries. > > Good thing is Golang is catching up with its own style. > > There are cases though where there is no equivalent

[go-nuts] Re: [golang-dev] Methods may not take additional type arguments

[-golang-dev, +golang-nuts] The list you probably want is golang-nuts This topic is discussed at some length in #49085 . Not, in particular, that this option has been considered for the original design and it does not solve all problems

[go-nuts] Help with GOLLVM

Hello, I've create a docker images with ubuntu 20.10 with GOLLVM, I'm using at the moment a simple test repository , I was able to create the ll file with the following command: go build -gccgoflags -static-libgo -x -work 1> transcript.txt 2>&1

[go-nuts] Re: Go 1.18 Beta 1 is released

On Tue, Dec 14, 2021 at 8:51 PM Cherry Mui wrote: There's a test regression with Go1.18beta1 on freebsd/amd64 and modernc.org/file. The log file (https://gitlab.com/cznic/builder/-/blob/cdca564a0543e9ad0441884e3c12f7c0a326bdab/logs/freebsd64) does not say much and I have not yet managed to

[go-nuts] Re: Go 1.18 Beta 1 is released

On Tue, Dec 14, 2021 at 8:51 PM Cherry Mui wrote: Let me report another failure that works, ie. tests build and pass, with Go1.17.5 but not with Go1.18beta1 jnml@darwin-m1:~$ GO111MODULE=off go get github.com/edsrzf/mmap-go jnml@darwin-m1:~$ cd edsrzf/mmap-go/

Re: [go-nuts] go1.18 beta1: method instantiation accepts builtin types

Ah, that makes sense, thanks. > Perhaps it would be better to require the type-parameter names in method declarations to have the same names as in the type declaration. I think this is something that linters should do one day. On Thursday, December 16, 2021 at 12:39:44 PM UTC+3

Re: [go-nuts] go1.18 beta1: method instantiation accepts builtin types

> The second confusing part is that you can't instantiate a parameterized type in the way you might expect I should have said "depending on the context, you can't *always* instantiate a parameterized type in the way you might expect". This obviously does work: r := Result[bool]{V: true} --

Re: [go-nuts] go1.18 beta1: method instantiation accepts builtin types

To me, the first confusing part is that in some places you need to write "T any" to accept any type (unconstrained), and in other places you can write bare "T" The second confusing part is that you can't instantiate a parameterized type in the way you might expect, so in this case Result[bool]

Re: [go-nuts] go1.18 beta1: method instantiation accepts builtin types

It doesn't do "complete nonsense". It's equivalent to writing `func (r Result[T])`, it just uses a different identifier for the type-parameter. I agree that this looks confusing, which is why you shouldn't do it. Perhaps it would be better to require the type-parameter names in method declarations

[go-nuts] go1.18 beta1: method instantiation accepts builtin types

I'm a bit confused about ability to change struct constraints in methods that it looks like a method definition for a specific type, but in reality it does complete nonsense: Here's an example: https://gotipplay.golang.org/p/zFLJMdp5mbO -- You received this message because you are subscribed