Re: [go-nuts] Re: Call the .net dlls into the golang

['Carla Pfaff' via golang-nuts]

Yes, you can call C functions from Go, it's called 
Cgo: https://go.dev/blog/cgo

On Wednesday 22 May 2024 at 18:04:19 UTC+2 Pavan Kumar A R wrote:

>
>> Okay,  it's possible to call the C program to Golang. Because I also have 
>> the C platform dlls and the C platform dlls  we using in the cross platform 
>> mono and in the mono internally call the.net dlls function , can I use 
>> the C program dlls in Golang?  
>>
>

-- 
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/7282ba6c-8700-44f0-bd97-5a61807c963en%40googlegroups.com.

[go-nuts] Re: Call the .net dlls into the golang

['Carla Pfaff' via golang-nuts]

You can't call .NET functions directly from Go. Go programs and .NET have 
two completely different runtimes. You would need some form of 
inter-process communication (IPC).

On Wednesday 22 May 2024 at 14:31:04 UTC+2 Pavan Kumar A R wrote:

> Hello ,
>
> I build the.net dlls in the target framework, which is.net-framework 2.0, 
> and inside the.net dlls are some functions. I want to call this function 
> in Golang. How can I call the.net function in Golang? Please help out 
> here. 
>

-- 
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/6ca2d475-9fd3-4549-9f8e-576d92ed70b5n%40googlegroups.com.

[go-nuts] Re: just started using modules, what have i missed?.

['Carla Pfaff' via golang-nuts]

It's not clear what your end goal is. github.com/vulkan-go/vulkan is a 
library. Do you want to use it as a dependency in one of your projects or 
not? If you want to use it as a dependency, then yes, "go mod init " 
your project first before adding a dependency with "go get".

On Thursday 2 May 2024 at 19:17:03 UTC+2 simon place wrote:

>
> *simon@fedora:~$ go get github.com/vulkan-go/vulkan 
> *
>
>
>
>
>
>
> *go: go.mod file not found in current directory or any parent directory. 
> 'go get' is no longer supported outside a module. To build and install a 
> command, use 'go install' with a version, like 'go install 
> example.com/cmd@latest ' For more 
> information, see https://golang.org/doc/go-get-install-deprecation 
>  or run 'go help get' or 
> 'go help install'.*
> *simon@fedora:~$ go install github.com/vulkan-go/vulkan 
> *
>
>
>
>
>
>
>
>
>
>
>
> *go: 'go install' requires a version when current directory is not in a 
> module Try 'go install github.com/vulkan-go/vulkan@latest 
> ' to install the latest 
> versionsimon@fedora:~$ go install github.com/vulkan-go/vulkan@latest 
> package 
> github.com/vulkan-go/vulkan  is not a 
> main packagesimon@fedora:~$ go get github.com/vulkan-go/vulkan@latest 
> go: go.mod file not found in 
> current directory or any parent directory. 'go get' is no longer supported 
> outside a module. To build and install a command, use 'go install' with a 
> version, like 'go install example.com/cmd@latest 
> ' For more information, see 
> https://golang.org/doc/go-get-install-deprecation 
>  or run 'go help get' or 
> 'go help install'.simon@fedora:~$ *
>
> so, i guess, i can make a dummy package that imports what i want, then  
> init + tidy + get and erase it all! if this is it, then a simple script is 
> needed, but surely im missing something.
>
> to me you need a lib package, with its documentation, first, in order to 
> try/test alternatives.
>
>

-- 
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/27700cd1-75d7-49ee-9959-459f04d06733n%40googlegroups.com.

Re: [go-nuts] Unhappy with the official generics tutorial

['Carla Pfaff' via golang-nuts]

On Thursday 22 February 2024 at 10:19:58 UTC+1 Jan Mercl wrote:

On Thu, Feb 22, 2024 at 10:06 AM 'Carla Pfaff' via golang-nuts 
 wrote: 

> This omission is notable considering "any" is among the most frequently 
used constraints in writing generic code. 

Interesting to know, I'd naively guess the opposite. Can you please 
share the source data set? Thank you.


In the standard library, the most notable packages that add generic 
functions are slices <https://pkg.go.dev/slices> and maps 
<https://pkg.go.dev/maps>. Almost all of their functions feature an 'any' 
constraint. Same for other generic additions to the standard library such 
as atomic.Pointer, reflect.TypeFor, and sync.OnceValue.

-- 
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/7e0656cf-876c-4a82-9760-40923261d722n%40googlegroups.com.

Re: [go-nuts] Unhappy with the official generics tutorial

['Carla Pfaff' via golang-nuts]

The feedback was not specific to the "SumIntsOrFloats" example in the 
tutorial. The tutorial fails to demonstrate any generic data structures 
utilizing the "[T any]" constraint or a function with an 'any' constraint, 
such as "slices.Clone[S ~[]E, E any](s S) S". This omission is notable 
considering "any" is among the most frequently used constraints in writing 
generic code.

On Thursday 22 February 2024 at 09:10:30 UTC+1 Kurtis Rader wrote:

I don't understand your feedback. How, exactly, should generics handle the 
`any` type? Documentation can always be improved but how would a generic 
function that accepts two `any` types perform addition of those "any" 
values?

 

-- 
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/c9c9e11b-9bf8-4ffd-b75e-ebb491962d63n%40googlegroups.com.

[go-nuts] Unhappy with the official generics tutorial

['Carla Pfaff' via golang-nuts]

The Go documentation, available at https://go.dev/doc/, features only one 
tutorial dedicated to generics, found at 
https://go.dev/doc/tutorial/generics. This tutorial lacks any examples 
employing the 'any' constraint, nor does it mention it. Instead, it begins 
with the use of an 'int64 | float64' constraint. These A|B constraints 
represent a more specialized application of generics, aimed at scenarios 
where there is a need to utilize an operator such as "+". However, the most 
universal, adaptable, and reusable form of a generic type or function — one 
that utilizes 'any' — is notably absent.

-- 
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/0447f6d6-6fe9-410f-9d5a-08bb20bba67en%40googlegroups.com.

[go-nuts] Re: GLog library can't be used in Golang 1.18 due to "abortProcess redeclared in this block" error

['Carla Pfaff' via golang-nuts]

glog_file_other.go uses the "unix" build constraint, which was introduced 
in Go 1.19: https://tip.golang.org/doc/go1.19#go-unix
Go 1.18 doesn't know about it. Since Go 1.18 is no longer supported (only 
the last two main releases are supported) it's either time to update your 
Go version to 1.19 or 1.20, or you have to stay on an older version of glog.

On Tuesday, 21 March 2023 at 15:40:38 UTC+1 Juan Antonio Cid Tomás wrote:

Hi there,

We have found an error in your library. We have created next test program:

package main

import (
"fmt"

_ "github.com/golang/glog"
)

func main() {
fmt.Println("Hello world")
}

Then we have enforced the usage of the latest changes (master branch), 
instead of the tagged ones:

$  go get -u github.com/golang/glog@master

Having GOOS="linux" in Golang 1.18 we get the next error when trying to 
build ($ go build ./...) the test program:

# github.com/golang/glog
../.asdf/installs/golang/1.18/packages/pkg/mod/
github.com/golang/gl...@v1.1.1-0.20230317133409-c0f9e3d764d3/glog_file_other.go:27:6
 
:
 
abortProcess redeclared in this block
../.asdf/installs/golang/1.18/packages/pkg/mod/
github.com/golang/gl...@v1.1.1-0.20230317133409-c0f9e3d764d3/glog_file_linux.go:33:6
 
:
 
other declaration of abortProcess
 
We don't get this error if we use Golang 1.19. 

We guess this error was caused when you splitted the usage of abortProcess in 
different files 
.
 
If you need more info regarding this don't hesitate to message me.
 

Best regards,

-- 
[image: Logotipo Cabify]Juanan Cid Tomás

Senior Engineer at Middleware
juanant...@cabify.com

[image: Logotipo Somos Neutros en Carbono]


Este mensaje y cualquier archivo adjunto va dirigido exclusivamente a su 
destinatario, pudiendo contener información confidencial sometida a secreto 
profesional. No está permitida su reproducción o distribución sin la 
autorización expresa de Cabify. Si usted no es el destinatario final por 
favor elimínelo e infórmenos por esta vía.

This message and any attached file are intended exclusively for the 
addressee, and it may be confidential. You are not allowed to copy or 
disclose it without Cabify's prior written authorization. If you are not 
the intended recipient please delete it from your system and notify us by 
e-mail.

-- 
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/8ae5d05b-1491-4587-b239-6d9267a2a738n%40googlegroups.com.

[go-nuts] Re: Best way to mark unused parameters/error values reported by linter

['Carla Pfaff' via golang-nuts]

If a linter reports false positives I don't use it. I would never uglify my 
source code to please a linter.

-- 
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/e3569bf4-4b64-4ce8-a20e-1d208baf7f74n%40googlegroups.com.

[go-nuts] Re: why strings.ToLower change the "Ⅱ" to "ii" ?

['Carla Pfaff' via golang-nuts]

It's actually "ⅱ" (one rune), not "ii" (two runes).
Because Unicode defines "ⅱ" (U+2171) as the lowercase character for "Ⅱ" 
(U+2161), see https://www.compart.com/en/unicode/U+2161

-- 
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/77e03f1f-a365-4f1f-8f0f-0253a8f616cbn%40googlegroups.com.

[go-nuts] Re: x/exp/slices: add Map/Extract function

['Carla Pfaff' via golang-nuts]

On Sunday, 20 March 2022 at 18:14:15 UTC+1 cpu...@gmail.com wrote:

> Has this already been discussed?
>

Yes: 
https://github.com/golang/go/discussions/47203#discussioncomment-1005237

-- 
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/f998ac4e-c4f0-4c0d-b016-5a5a16ee17f7n%40googlegroups.com.

Re: [go-nuts] Re: Tour of Go seems to be broken.

['Carla Pfaff' via golang-nuts]

On Thursday, 25 November 2021 at 18:43:44 UTC+1 bmar...@gmail.com wrote:

> I often give some training in my company about Go and I recommend the Tour 
> of Go as introducing but since September, french Tour of Go returns a http 
> 500 error (cf. my previous message 
> https://groups.google.com/g/golang-nuts/c/o8pBT6_z9OU/m/0q4Hn2JLAgAJ ) 
> and it seems to be still the case currently (page 
> https://go.dev/tour/welcome/2 --> select french --> 
> https://go-tour-fr.appspot.com/ = broken !)


The translated tours aren't maintained by the Go team. This one is 
https://github.com/dupoxy/go-tour-fr/issues/42 
The Go team can only remove unmaintained translations.

-- 
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/2acdce84-51c4-4e5e-847f-28c522f524c4n%40googlegroups.com.

[go-nuts] Re: New site go.dev is awful

['Carla Pfaff' via golang-nuts]

On Wednesday, 24 November 2021 at 22:53:33 UTC+1 ben...@gmail.com wrote:

> 2) The download link is for the Windows binary, and I'm running Linux. 
> Would be nice if it could try to auto-detect based on my User-Agent, which 
> includes the words "X11", "Ubuntu", and "Linux". 
>

The website already does this. At least on macOS I get the Mac version 
download link. Maybe there's a problem with the Linux User-Agent detection 
... yes, the 'setDownloadLinks' function currently only distinguishes 
between 'isMac' or not:
https://github.com/golang/website/blame/e0eb9bf3b15f4bee74782e245d3db37177b46822/_content/js/site.js#L131

-- 
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/fa479175-7c15-45f0-92e6-c6ec73280474n%40googlegroups.com.

[go-nuts] Re: New site go.dev is awful

['Carla Pfaff' via golang-nuts]

On Tuesday, 23 November 2021 at 19:46:19 UTC+1 poe...@gmail.com wrote:

> I can't think of one thing I like about the new site compared to the old 
> one, and would like to see the old site make a comeback.
>

Whenever a popular website launches a redesign a certain percentage don't 
like it. I've been on the internet for 24 years and witnessed it countless 
times. I've never once seen that time got turned back because of the 
complaints. 

-- 
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/64e3cafb-74fe-4ded-98af-dd83f050e6d0n%40googlegroups.com.

[go-nuts] Re: macos file provider handling with golang

['Carla Pfaff' via golang-nuts]

On Friday, 24 September 2021 at 18:00:21 UTC+2 va...@selfip.ru wrote:

> Hi. Does anybody knows how to call macos functions from go? 
> Mostly my question about file provider methods, i want to write 
> something that works as file provider for macos
>

https://github.com/progrium/macdriver
"MacDriver is a toolkit for working with Apple/Mac APIs and frameworks in 
Go."
 

-- 
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/c9321e1c-2999-4590-a94b-57de6e3e3c59n%40googlegroups.com.

[go-nuts] Re: Where can I get a complete list of enhancements or changes of the golang spec (Version of Feb 10, 2021) agaisnt previous (Version of Jan 14, 2020)

['Carla Pfaff' via golang-nuts]

On Saturday, 12 June 2021 at 16:53:01 UTC+2 Benjamin wrote:

>
> Previously it took a long time to read through the golang spec of version 
> of Jan 14, 2020. The newest golang spec is Version of Feb 10, 2021. I 
> really don't want to read through all the spec again. Is there a summary on 
> the changes between the two versions? Thanks.


Check out the Go repository and do

git diff ee55dd6b doc/go_spec.html

-- 
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/7f13aba2-d50b-477a-bb7d-900a9a6dd329n%40googlegroups.com.

[go-nuts] Re: gonum plot : font error

['Carla Pfaff' via golang-nuts]

You should really use modules. The module name is "gonum.org/v1/plot", not 
"github.com/gonum/plot".

$ mkdir scatter-demo
$ cd scatter-demo
$ go mod init scatter-demo
$ edit main.go
# Copy and paste code from 
https://gist.github.com/sbinet/602522b7399ead414e279e2261d81095 into main.go
# Replace all instances of "github.com/gonum/plot" by "gonum.org/v1/plot" 
in the imports of main.go:

"gonum.org/v1/plot"

"gonum.org/v1/plot/plotter"

"gonum.org/v1/plot/vg"
$ go mod tidy
$ go build

On Monday, 17 May 2021 at 14:11:01 UTC+2 Fred wrote:

> Hi,
> I have 2 computers with Linux Manjaro and  go version 1.16.3.
> The same scatter plot 
>  works 
> on one computer and produces on the other these already known errors : 
> 
>
> # gonum.org/v1/plot/text
> /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:153:3: cannot use 
> hdlr.Fonts.Lookup(rm, fnt.Size).Face (type *sfnt.Font) as type 
> *truetype.Font in field value
> /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:154:3: cannot use 
> hdlr.Fonts.Lookup(rm, fnt.Size).Face (type *sfnt.Font) as type 
> *truetype.Font in field value
> /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:155:3: cannot use 
> hdlr.Fonts.Lookup(it, fnt.Size).Face (type *sfnt.Font) as type 
> *truetype.Font in field value
> /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:156:3: cannot use 
> hdlr.Fonts.Lookup(bf, fnt.Size).Face (type *sfnt.Font) as type 
> *truetype.Font in field value
> /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:157:3: cannot use 
> hdlr.Fonts.Lookup(bfit, fnt.Size).Face (type *sfnt.Font) as type 
> *truetype.Font in field value
> /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:221:3: cannot use 
> op.Glyph.Font (type *truetype.Font) as type *sfnt.Font in field value
>
> an update does not fix the error.
>
> go get -u gonum.org/v1/plot/...
> # cd /home/fred/GO/src/github.com/go-latex/latex; git pull --ff-only
> Votre information de configuration indique de fusionner avec la référence 
> 'refs/heads/master'
> du serveur distant, mais cette référence n'a pas été récupérée.
> package github.com/go-latex/latex/drawtex: exit status 1
>
> the go/src/gonum.org/v1/plot/font directory is the same on both 
> computers. Do I need to install some missing fonts ?
>
> Thanks in advance,
>
> Fred
>
>

-- 
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/0bff84b8-0756-42df-8604-3035a861f9e7n%40googlegroups.com.

[go-nuts] Re: Go module dependency debugging workflow

['Carla Pfaff' via golang-nuts]

On Friday, 9 April 2021 at 17:38:12 UTC+2 gonutz wrote:

> I could create a local commit to the library or create a new debug branch 
> in my local copy of the library. Then I insert my debug code and commit it. 
> Then I point my main program's go.mod file at the new commit/branch, adding 
> a replace along the way to use my local copy. Then when I am done debugging 
> I roll everything back. This works but is very annoying for just a 
> temporary print statement here and there.
>

Use the local replace with the v0.0.0-unpublished pseudo-version number, 
then you don't have to commit and roll back all the time.

-- 
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/5519907c-470b-471b-96b5-7610fc4ebb01n%40googlegroups.com.

[go-nuts] Re: Modules... why it has to be so painfull?

['Carla Pfaff' via golang-nuts]

On Friday, 9 April 2021 at 17:38:12 UTC+2 gonutz wrote:

> A replace in the go.mod file is of no help here because I still have to 
> specify a require with a concrete version or commit hash for the library. 
> This means I cannot just change the code in the library module, I also have 
> to create a commit and check it in, then go back to my main module and 
> udpate not only the replace but also the require in go.mod, every time I 
> want to simply place a simple, temporary print statement for debugging 
> purposes into the library.
>
> Does anybody have an easy workflow for the common use case?
>

https://golang.org/doc/modules/managing-dependencies#local_directory 

-- 
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/7eb50cc0-9244-4169-80db-3d03fd2e017fn%40googlegroups.com.

Re: [go-nuts] Modules... why it has to be so painfull?

['Carla Pfaff' via golang-nuts]

On Thursday, 8 April 2021 at 12:48:28 UTC+2 nick@gmail.com wrote:

> But what if you don't even have a domain for your source code? Sure you 
> can use a fake domain like "foo.example"
>

It doesn't have to be a fake domain name, just a module name, e.g. "foo".
 

> and then use replace, and then remember to not commit the replace because 
> someone else may have the code in a different location, etc etc. Imagine if 
> it was the other way around:
>
> my_source_location/
> ProjectA/
> go.mod
>   module ProjectA
>   replace /home/nick/src/ProjectA => mydomain.com/group/ProjectA
> ProjectB/
> go.mod
>   module ProjectB
>   replace /home/nick/src/ProjectB => mydomain.com/group/ProjectB
>

If you're only tinkering without publishing you can put the go.mod directly 
under "my_source_location", then you have your own GOPATH-like environment.

-- 
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/57f57bcf-2c13-4a98-936f-8f7f54b4351en%40googlegroups.com.

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

['Carla Pfaff' via golang-nuts]

On Thursday, 8 April 2021 at 02:11:50 UTC+2 rob wrote:

> Yes, you are absolutely correct that I've been struggling w/ modules. 
>
> Would it be a bad idea to use my ~go/src as a module? 
>
>   cd ~/go/src 
>
>   go mod init src 
>
>   go mod tidy --> do I need this? 
>
> And then I would have to edit my import statements slightly to include 
> the module reference. 
>
> --rob solomon 
>

That's basically what I suggested to you in my response. Only, instead of 
 "~/go/src" I called it "rob".

-- 
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/405db51e-f98a-48a5-9369-42b0f973dbacn%40googlegroups.com.

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

['Carla Pfaff' via golang-nuts]

On Tuesday, 6 April 2021 at 02:13:14 UTC+2 rob wrote:

> I'm still struggling w/ modules to get my code to compile.  This example 
> is on Win10 using go 1.16.3 
>
> ~/go/src/rpng/rpng.go 
> ~/go/src/tokenize/tokenize.go 
> ~/go/src/hpcalc2/hpcalc2.go 
>
>
Put them in a directory, e.g. "rob". This can be anywhere, it doesn't have 
to be under "~/go/src":

  rob/rpng/rpng.go 
  rob/tokenize/tokenize.go 
  rob/hpcalc2/hpcalc2.go

 In each of my directories in ~/go/src, I've run 
>
> go mod init  
>

Delete these go.mod/go.sum files that you created in the sub-directories.

Then go in the "rob" directory and init the module "rob":

  cd rob
  go mod init rob

Result:

  rob/go.mod
  rob/go.sum
  rob/rpng/rpng.go 
  rob/tokenize/tokenize.go 
  rob/hpcalc2/hpcalc2.go

Now always import the packages with the module prefix "rob/":

  import "rob/rpng"
  import "rob/tokenize"
  ...

-- 
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/881ade6d-21cd-43dd-ade1-2aeb983a0738n%40googlegroups.com.

Re: [go-nuts] Re: now that the election is over can we please remove the political ad for golang.org

['Carla Pfaff' via golang-nuts]

It's not an uncommon practice for teams that run a public website to raise 
awareness for a good cause, usually by supporting fundraising for a social 
nonprofit charitable organization. Some choose a children's cancer charity 
or the Wikimedia foundation, this is what the Go team chose. This does not 
mean that other issues in the world are not important.

The Go project has never been a sterile place, it always had a personal 
touch from its creators, see for example the cute gopher drawings. It's 
also not a science centric community (btw, science is political too, always 
has been) nor is the Go website the Mona Lisa.

-- 
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/71e4034a-1e14-423f-a476-5c7c7749049dn%40googlegroups.com.

[go-nuts] Re: nice user survey re Go-lang

['Carla Pfaff' via golang-nuts]

It's a nice survey indeed. This is the original source of the article: 
https://blog.golang.org/survey2020-results

-- 
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/73fddfcb-ca57-4eee-9253-784d90e1bb2en%40googlegroups.com.

Re: [go-nuts] How to search standard libarary?

['Carla Pfaff' via golang-nuts]

On Tuesday, 16 March 2021 at 16:53:01 UTC+1 jake...@gmail.com wrote:

>  I would love to hear from someone involved why the go team decided to 
> remove this feature from the official Go website. 
>

The reasons for removing the search are documented in the accompanying 
issue: https://github.com/golang/go/issues/44357 

-- 
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/3c92658f-6da3-4b2b-ad11-2712f7a62637n%40googlegroups.com.

[go-nuts] Re: How to search standard libarary?

['Carla Pfaff' via golang-nuts]

On Tuesday, 16 March 2021 at 15:09:25 UTC+1 jake...@gmail.com wrote:

> Any suggestions?


You can use this: https://cs.opensource.google/go 

-- 
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/50f638e7-f6b3-4db9-bea5-6a76aafb5ba9n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

['Carla Pfaff' via golang-nuts]

On Saturday, 13 March 2021 at 15:31:05 UTC+1 Space A. wrote:

> There wasn't even a poll or anything. So the question of whether this 
> topic should be dropped completely (a lot of reasons why) has not been 
> thought out.
>

It was already explained that Go development is not driven by polls or 
surveys: 
https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/uGjSw4VGBgAJ
You were in the same thread, you should already know this.

-- 
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/609679d4-5155-43e8-8e2d-4abea18f0874n%40googlegroups.com.

Re: [go-nuts] sort string slice like it contains key,val

['Carla Pfaff' via golang-nuts]

On Saturday, 13 March 2021 at 14:44:05 UTC+1 mlevi...@gmail.com wrote:

> the sort package from the stdlib, it contains an interface that you can 
> easily implement for such problematics :)
>

Like this: https://play.golang.org/p/eoLJ2aVAWkD
 

-- 
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/b8caea5d-fc98-41cf-85aa-b1526105840bn%40googlegroups.com.

[go-nuts] Re: go get v git clone

['Carla Pfaff' via golang-nuts]

You use git clone. Go get is for adding a dependency to a project.

Also how do I delete something I go getted?
>
 
~/go/pkg/mod is just a local cache, nothing you work in. You can clear the 
whole module cache with go clean -modcache

-- 
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/bbb9fabf-9f15-4470-b3de-db809aa26d3en%40googlegroups.com.

[go-nuts] Re: How do you test an unpublished module?

['Carla Pfaff' via golang-nuts]

The modules documentation has a section on this: "Developing and testing 
against unpublished module code"
https://golang.org/doc/modules/managing-dependencies#tmp_9

On Saturday, 20 February 2021 at 13:10:38 UTC+1 pkle...@xs4all.nl wrote:

> Is there a way to tell go.mod that it should use local files instead
> of a repository, just for the development phase?
>
>

-- 
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/d24ecd3b-72f7-4313-9bd4-8ffacd42e643n%40googlegroups.com.

Re: [go-nuts] Error handling

['Carla Pfaff' via golang-nuts]

On Thursday, 18 February 2021 at 09:34:35 UTC+1 Amnon wrote:

> OT, but what has happened to the Go 2 error handling proposals?
> I heard that the original check proposal was abandoned because of the 
> unfortunate interaction with defer. 
>
> Any updates?


After the "check" proposal the Go team made another proposal, the "try" 
proposal, but it was rejected as well. Now error handling is on the 
back-burner and they are focusing on generics:
https://github.com/golang/go/issues/32437#issuecomment-513002788
"Also, realistically, since we don't have unlimited resources, I see 
thinking about language support for error handling go on the back-burner 
for a bit in favor of more progress on other fronts, most notably work on 
generics"

-- 
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/c60af668-55d6-4977-a746-b04dbc67e31an%40googlegroups.com.

[go-nuts] Re: go get not working in Go 1.16

['Carla Pfaff' via golang-nuts]

On Tuesday, 16 February 2021 at 22:57:07 UTC+1 pkle...@xs4all.nl wrote:

> Also, you can't use local packages without a dot in the name.
>

I do this all the time.

-- 
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/61ae8671-1e1c-4136-9c3a-496297c5fd98n%40googlegroups.com.

[go-nuts] Re: Is it possible to embed generic structs with go2go?

['Carla Pfaff' via golang-nuts]

It seems to be this issue: https://github.com/golang/go/issues/40814

-- 
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/764b60cd-4f94-4341-ab2c-35bf38388197n%40googlegroups.com.

[go-nuts] Re: calling cmd

['Carla Pfaff' via golang-nuts]

"htop" doesn't exit (the channel read blocks until exit), and it uses ANSI 
escape codes for colorful output. You'd be better served by "top -b -n 1" 
(Linux) or  "top -l1" (macOS).

-- 
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/14196080-4cc4-41ae-bbee-87a198b7fc8cn%40googlegroups.com.

Re: [go-nuts] What compatibility of go/ast, go/types, go/packages packages is planned, if any, when transitioning toward go2 ?

['Carla Pfaff' via golang-nuts]

On Wednesday, 27 January 2021 at 23:28:17 UTC+1 Ian Lance Taylor wrote:

> To be clear, there is no Go 2, and there are no plans for Go 2. 
>

For someone who follows the mailing lists and issue comments this has been 
known for a while, but it's easy to see where the confusion comes from, 
given these blog posts:

https://blog.golang.org/toward-go2
https://blog.golang.org/go2-here-we-come
https://blog.golang.org/go2-next-steps

They mention backward-compatibility, but only for the initial proposals "to 
get the ball rolling". There hasn't been a blog post titled "There are no 
plans for Go 2" or "Go 2 is not what you think it is" so far. The current 
policy seems to be this document:

"Proposal: Go 2 transition": 
https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md
"If the above process works as planned, then in an important sense there 
never will be a Go 2."

It is labeled "Proposal", but it doesn't seem to be a proposal in the usual 
proposal process sense, and many may have missed it.
 

-- 
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/2b24821f-bf51-4723-b358-73c2c20e19d6n%40googlegroups.com.

[go-nuts] Re: program times out on go playground and runs but with race on mac running go1.16beta

['Carla Pfaff' via golang-nuts]

result <- Event{event, err}

reads the `err` variable in one goroutine, and

err = watcher.Add(dir)

writes the same `err` variable in another goroutine.

-- 
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/3f5c429e-5b5b-495d-8cf1-1e4dceb5d299n%40googlegroups.com.

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

['Carla Pfaff' via golang-nuts]

On Wednesday, 20 January 2021 at 10:05:24 UTC+1 cham...@gmail.com wrote:

> A bit out of subject but the naming with generics has always bothered me. 
> It's more of an general observation and don't have a solution for it.
> I think we all agree that naming types and variables is important. Why for 
> generics we accept that naming them E, K P, T etc.. is good and sufficient?
>

Also, until now, in Go identifiers beginning with a capital letter are 
exported.
I personally liked the lower case identifiers they used in the 
Featherweight Go paper (and for type parameters in Haskell). On the other 
hand, I can see that many people are familiar with the T & Co. from C++ and 
its various derivatives.
I don't have strong feelings either way, but it may be a chance to make a 
better choice than other language ecosystems.

-- 
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/b7ba359f-09b6-4d8a-b19f-1d53717a315en%40googlegroups.com.

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

['Carla Pfaff' via golang-nuts]

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 proposal. You can easily use 
lowercase letters/identifiers: https://go2goplay.golang.org/p/eWgJSLNTZw8

-- 
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/2e2593bd-f88e-4d2e-9ebe-0949cb00688bn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

['Carla Pfaff' via golang-nuts]

On Tuesday, 22 December 2020 at 20:09:42 UTC+1 al...@pbrane.org wrote:

> Please don't minimize or silence the lived experience 
> of people disproportionately affected by generics. 
>
> We should protect non-generic function bodies. 
>
> Concrete code matters. 
>

Tasteless attempt at humour.

-- 
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/20893718-5fd6-4ab9-b2bb-5742ef042d3cn%40googlegroups.com.

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

['Carla Pfaff' via golang-nuts]

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 ensures that the type has at 
least 0 methods and all of these 0 methods must match the 0 methods of the 
interface. An empty purse is still a purse, an empty constraint is still a 
constraint.
 

> My problem is the attractiveness of "any" as a return type. 
>

I don't see why anybody would find it attractive as a return type. People 
don't use the empty interface because they like it so much, but because Go 
doesn't have parametric polymorphism / "generics" yet. There are many 
programming languages that have a named top type and it is rarely abused. 
Programmers want to write type safe code if they can.

-- 
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/8e5b46ba-7a3e-4d55-ac97-1e70d06e622dn%40googlegroups.com.

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

['Carla Pfaff' via golang-nuts]

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 means that the value is an interface, and you have to get 
> the value from that interface. Different uses, different identifiers. 

 
The same is true for "interface{String() string}" as a constraint and 
"interface{String() string}" as a type.
Does that mean that you want to allow the identifier "fmt.Stringer" only 
for constraints, but not for types?

-- 
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/4c9a2735-3e22-4568-ac0b-8c6a8b4b8583n%40googlegroups.com.

Re: [go-nuts] Re: module confusion

['Carla Pfaff' via golang-nuts]

People and installers usually install Go in /usr/local/go on Unix-like 
systems.

~/go is the default GOPATH if not set, so ~/go/bin is where binaries 
installed via "go get" / "go install" land. But the Go distribution itself 
must not be under GOPATH.

-- 
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/fb4aeee2-53fd-49cd-b42c-b247ad332e4bn%40googlegroups.com.

[go-nuts] Re: module confusion

['Carla Pfaff' via golang-nuts]

This has nothing to do with modules. You're still using the old GOPATH 
mode, because you're not in a directory with a go.mod file. GOPATH defaults 
to $HOME/go when it's not set (since 1.8), but that's where you chose to 
put your Go installation. This is not allowed. Either install Go to a 
different location, or set GOPATH to a different location.

-- 
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/722d0683-ceaf-4e7e-81a5-996e9abc5fabn%40googlegroups.com.

[go-nuts] Re: [generics] How to use maps in generic structs?

['Carla Pfaff' via golang-nuts]

K and V must be comparable, since you use them as map keys:

type BiMap[type V, K comparable] struct {
forward map[K]V
reverse map[V]K 
}

-- 
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/202f1ffa-ac89-42eb-b617-d82e14c537een%40googlegroups.com.

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

['Carla Pfaff' via golang-nuts]

On Monday, 10 August 2020 at 10:30:55 UTC+2 Ivan Ivanyuk wrote:

> There is already an instrument in playground that works fine. Why not just 
> roll it out and improve design, if needed, in next version?
>

The go2go tool is just a toy, an experiment, a simple translation tool. It 
will be thrown away once they begin with the real implementation.

https://twitter.com/GoTimeFM/status/1292148677155463169
(Transcript from the Go Time podcast): *"The experimental tool has no 
similarity whatsoever to any real implementation. [...] If this does move 
forward to become a proposal and it gets accepted, then most likely the 
implementation will be to start with a branch of the main Go toolchain, and 
we'll start adding generic support on that branch, which will involve 
changing the compiler mainly and any other changes to other tools that are 
required."*
 

> Having generics in 2021 means many projects will choose other languages in 
> 2020, which will effectively mean 1 year of work in other language
>

Go aims at careful and cautious language design, not at catering to 
impatient people. 

-- 
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/71456b53-eb1f-4229-a103-1cd6c1397e7cn%40googlegroups.com.

[go-nuts] Re: Generics: after type lists

['Carla Pfaff' via golang-nuts]

On Saturday, 8 August 2020 at 01:33:59 UTC+2 Patrick Smith wrote:

> if we think it likely that a future version of Go will allow operator 
> overloading
>

That's highly unlikely: https://golang.org/doc/faq#overloading 

-- 
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/eb62bd8d-9310-4eb4-8125-bebda7bd6594n%40googlegroups.com.

[go-nuts] Re: Modifying Source code and build go from the source.

['Carla Pfaff' via golang-nuts]

Well, it says "lock_futex.go:152:2: ns declared but not used". An unused 
variable is a compile error in Go.

On Friday, 7 August 2020 at 09:54:23 UTC+2 Yosef Yo wrote:

> /home/nn/Downloads/go/src/runtime/lock_futex.go:152:2: ns declared but not 
> used
>
> go tool dist: FAILED
>

-- 
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/7520453b-019c-4bf8-ab98-0844321d7e6dn%40googlegroups.com.

Re: [go-nuts] A few thoughts on type parameters

['Carla Pfaff' via golang-nuts]

On Tuesday, 4 August 2020 at 00:34:12 UTC+2 ben...@gmail.com wrote:

> Which at first seems like a good idea, but then unless "any" is built in 
> or this becomes a well-known idiom, it won't be as self-documenting. Other 
> people will have to look up the definition to see "oh, I see, this is just 
> short-hand for an empty constraint".


I'm sure it would quickly become a well-known idiom, just like people know 
that "error" is "interface{Error() string}" or "fmt.Stringer" is 
"interface{String() string}".

Actually the current use of "interface{}" is a bit odd because it is the 
only case where an interface is commonly used as an anonymous type rather 
than by an identifier.

I assume that in current Go the empty interface is supposed to be an ugly 
duckling to discourage its overuse, but in a world with type parameters it 
will play an important role as the unbounded constraint and it should 
deserve its own identifier.

And I don't think that giving it a short name would encourage more use of 
the empty interface as a type for regular function parameters, because my 
estimate is that people are happy to use "generics" rather than the empty 
interface in function parameters when they can. Most Go programmers want to 
be type safe and avoid casting.

-- 
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/a4d6050c-5e44-4849-a682-80a808d12417n%40googlegroups.com.

Re: [go-nuts] A few thoughts on type parameters

['Carla Pfaff' via golang-nuts]

On Monday, 3 August 2020 at 19:46:05 UTC+2 Ian Lance Taylor wrote:

> Yet another possibility, going back to the syntax question above, is 
> requiring that a type parameter for a type alway have a constraint, 
> which would mean that we would never use the "type" keyword for type 
> parameters, and define a predeclared identifier "any = interface{}". 
>

Thanks for considering this possibility. Why I like it:

   - Type parameter lists and function parameter lists have the same 
   structure. Constraint is to type parameter as type is to function parameter.
   - Even more symmetry between declaration and instantiation than before: 
   No "type" keyword at instantiation, no "type" keyword at declaration.
   - Type parameter lists do not suddenly take on a different shape when 
   they are a mixture of constrained and unconstrained type parameters 
   compared to fully unconstrained type parameter lists:
  - Without "type" keyword
 - [A, B any] and [A any, B comparable] // No surprise
  - With "type" keyword
 - [type A, B] and [type A interface{}, B comparable] // A wild 
 interface{} appears!
  

-- 
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/177f43c1-70d9-4c24-8eee-e2e02cc81925n%40googlegroups.com.

[go-nuts] Re: Why we don't have simple throws error statement

['Carla Pfaff' via golang-nuts]

Your "throws" statement (why is it called "throws" when it "catches" 
according to the comment?) looks a lot like the "handle" block from the 
first draft design by the Go team: the check/handle proposal 

.

On Friday, 31 July 2020 at 16:06:33 UTC+2 semi...@gmail.com wrote:

> Hey Community,
>
> I know, there are so many discussion about error handling. I read tons of 
> idea about that. Looks like most of idea rejected from community but every 
> idea brings our goal closer.
>
> May be we need simple solution. I like Go's simplest ways always. I don't 
> think so we need complex solution about that. Could we handle complexity 
> the error checking with simple throws statement?
>
>
> func myFileRDWRFunc(filename string) (string, error) {
>f, err := os.OpenFile(filename, os.O_RDWR, 0600)
>if err != nil { // backward compatibility
>return "", err
>}
>
> throws func(err error) { // catch all errors
>log.Println(err)
>f.Close()
>
> return "", err
>}()
>
> f.WriteString("anystring")
>f.Seek(0, 0)
> b := ioutil.ReadAll(f)
>
> return string(b), nil
> }
>
> Cheers.
>
> Semih.
>
>

-- 
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/9b52a293-eb4c-462b-9d64-56a345348a5cn%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

['Carla Pfaff' via golang-nuts]

On Sunday, 26 July 2020 at 07:06:16 UTC+2 Carla Pfaff wrote:

> Maybe gofmt could rewrite "interface{}" to "any", so there won't even be 
> such a question for new code.
>

When I think about it, that's probably not possible for gofmt to do in a 
safe way. 

-- 
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/c9273c12-040d-41f8-9097-dc68909da831n%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

['Carla Pfaff' via golang-nuts]

On Sunday, 26 July 2020 at 03:13:30 UTC+2 Denis Cheremisov wrote:

> The bad with *any* in builtins is there will be questions "why you use 
> interface{}" if there's builtin *any?*", etc.


If Go has generics I expect that people will use "interface{}"/"any" a lot 
less outside of type parameter lists than today. Maybe gofmt could rewrite 
"interface{}" to "any", so there won't even be such a question for new code.

-- 
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/7dde60a4-7eca-413a-938c-a2e5d47c4c1an%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

['Carla Pfaff' via golang-nuts]

I don't see why it should be in the grammar. Just a regular type alias for 
interface{} in the builtin scope, a regular predeclared identifier. It 
wouldn't break anyone's code. If someone already has an 'any' type or 
variable in their package their version shadows the builtin one, and they 
can still use interface{} as a generic type constraint. At least that's how 
it works with other builtin type aliases like 'rune': 
https://play.golang.org/p/KRX3fIBV9qW

-- 
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/99559372-bcc5-4a12-aca1-6af1cf62931bn%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

['Carla Pfaff' via golang-nuts]

On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote:

> Note that in this way constraints on type parameters are different 
> from types of regular parameters. It makes no sense to speak of a 
> regular parameter with no type.
>

In regular parameter lists interface{} has this role, same as in type 
parameter lists, and we do not omit it. I know interface{} is technically a 
type, but "no constraint" is technically a constraint too.

-- 
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/eecc8431-8cf5-48db-8a52-f15ef385ceb7n%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

['Carla Pfaff' via golang-nuts]

There's already a precedent of a builtin type alias in Go with "type rune = 
int32" https://golang.org/pkg/builtin/#rune and "any" would make many 
regular parameter lists shorter as well.

On Saturday, 25 July 2020 at 22:37:39 UTC+2 Carla Pfaff wrote:

> I know it's common to have no constraints, but "[Elem any]" is even one 
> character shorter than "[type Elem]". I rewrote the function signatures 
> from slices.go2 in this way, and it doesn't feel painful. This already 
> works on the go2go playground: https://go2goplay.golang.org/p/IQV5LTAIuDr
>
> On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote:
>
>> On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts 
>>  wrote: 
>> > 
>> > To expand on my post: 
>> > It would be very consistent with the structure of regular parameter 
>> lists. Just like every parameter in a regular parameter list must have a 
>> type (with the exception of multiple consecutive parameters having the same 
>> type), every type parameter in a type parameter list must have a 
>> constraint. 
>>
>> That is certainly true. 
>>
>> But it is also true, based on experiments writing generic code, that 
>> the majority of type parameters have no constraints. That is 
>> particularly true for type parameters of generic types. So while it 
>> would be possible to require people to always explicitly write a 
>> constraint, it seems painful to force people to always write something 
>> that is almost never needed. 
>>
>> Note that in this way constraints on type parameters are different 
>> from types of regular parameters. It makes no sense to speak of a 
>> regular parameter with no type. It's entirely reasonable, even 
>> common, to speak of a type parameter with no constraint. 
>>
>> Ian 
>>
>>
>> > On Saturday, 25 July 2020 at 20:26:37 UTC+2 Carla Pfaff wrote: 
>> >> 
>> >> I just discovered the experiment to make the "type" keyword optional 
>> in certain cases on the dev.go2go branch. The commit message says: 
>> >> 
>> >> --- 
>> >> Experiment: Make "type" keyword optional in generic type declarations 
>> when 
>> >> it is clear that we can't have an array type declaration. This is the 
>> case 
>> >> when we have one the following: 
>> >> 
>> >> - more than one type parameter 
>> >> - a type parameter with a constraint 
>> >> - a trailing comma in the type parameter list 
>> >> -- 
>> >> 
>> >> If the "type" keyword is not necessary if a constraint is present, 
>> then why not make a constraint mandatory and get rid of the "type" keyword 
>> in type parameter lists altogether? 
>> >> 
>> >> Before: 
>> >> 
>> >> func Filter[type Elem](...) 
>> >> func Map[Elem1, Elem2](...) 
>> >> func Max[Elem constraints.Ordered](...) 
>> >> 
>> >> After: 
>> >> 
>> >> func Filter[Elem interface{}](...) 
>> >> func Map[Elem1, Elem2 interface{}](...) 
>> >> func Max[Elem constraints.Ordered](...) 
>> >> 
>> >> "interface{}" may be a little bulky, especially it since it is usually 
>> used for the simple cases. But if there was a short type alias for 
>> "interface{}" like "any" it can look good: 
>> >> 
>> >> type any = interface{} 
>> >> 
>> >> func Filter[Elem any](...) 
>> >> func Map[Elem1, Elem2 any](...) 
>> >> func Max[Elem constraints.Ordered](...) 
>> >> 
>> > -- 
>> > 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...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%40googlegroups.com.
>>  
>>
>>
>

-- 
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/e51a52ce-b683-49cc-86f5-2ce8ca1e0367n%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

['Carla Pfaff' via golang-nuts]

I know it's common to have no constraints, but "[Elem any]" is even one 
character shorter than "[type Elem]". I rewrote the function signatures 
from slices.go2 in this way, and it doesn't feel painful. This already 
works on the go2go playground: https://go2goplay.golang.org/p/IQV5LTAIuDr

On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote:

> On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts
>  wrote:
> >
> > To expand on my post:
> > It would be very consistent with the structure of regular parameter 
> lists. Just like every parameter in a regular parameter list must have a 
> type (with the exception of multiple consecutive parameters having the same 
> type), every type parameter in a type parameter list must have a constraint.
>
> That is certainly true.
>
> But it is also true, based on experiments writing generic code, that
> the majority of type parameters have no constraints. That is
> particularly true for type parameters of generic types. So while it
> would be possible to require people to always explicitly write a
> constraint, it seems painful to force people to always write something
> that is almost never needed.
>
> Note that in this way constraints on type parameters are different
> from types of regular parameters. It makes no sense to speak of a
> regular parameter with no type. It's entirely reasonable, even
> common, to speak of a type parameter with no constraint.
>
> Ian
>
>
> > On Saturday, 25 July 2020 at 20:26:37 UTC+2 Carla Pfaff wrote:
> >>
> >> I just discovered the experiment to make the "type" keyword optional in 
> certain cases on the dev.go2go branch. The commit message says:
> >>
> >> ---
> >> Experiment: Make "type" keyword optional in generic type declarations 
> when
> >> it is clear that we can't have an array type declaration. This is the 
> case
> >> when we have one the following:
> >>
> >> - more than one type parameter
> >> - a type parameter with a constraint
> >> - a trailing comma in the type parameter list
> >> --
> >>
> >> If the "type" keyword is not necessary if a constraint is present, then 
> why not make a constraint mandatory and get rid of the "type" keyword in 
> type parameter lists altogether?
> >>
> >> Before:
> >>
> >> func Filter[type Elem](...)
> >> func Map[Elem1, Elem2](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> >> After:
> >>
> >> func Filter[Elem interface{}](...)
> >> func Map[Elem1, Elem2 interface{}](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> >> "interface{}" may be a little bulky, especially it since it is usually 
> used for the simple cases. But if there was a short type alias for 
> "interface{}" like "any" it can look good:
> >>
> >> type any = interface{}
> >>
> >> func Filter[Elem any](...)
> >> func Map[Elem1, Elem2 any](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%40googlegroups.com
> .
>

-- 
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/751b84b1-c3b6-4b81-8b9d-845805dc1ae5n%40googlegroups.com.

[go-nuts] Re: [generics] Feedback on optional type keyword experiment

['Carla Pfaff' via golang-nuts]

To expand on my post:
It would be very consistent with the structure of regular parameter lists. 
Just like every parameter in a regular parameter list must have a type 
(with the exception of multiple consecutive parameters having the same 
type), every type parameter in a type parameter list must have a 
constraint. 

On Saturday, 25 July 2020 at 20:26:37 UTC+2 Carla Pfaff wrote:

> I just discovered the experiment to make the "type" keyword optional in 
> certain cases on the dev.go2go branch. The commit message says:
>
> ---
> Experiment: Make "type" keyword optional in generic type declarations 
> when
> it is clear that we can't have an array type declaration. This is the 
> case
> when we have one the following:
> 
> - more than one type parameter
> - a type parameter with a constraint
> - a trailing comma in the type parameter list
> --
>
> If the "type" keyword is not necessary if a constraint is present, then 
> why not make a constraint mandatory and get rid of the "type" keyword in 
> type parameter lists altogether?
>
> Before:
>
> func Filter[type Elem](...)
> func Map[Elem1, Elem2](...)
> func Max[Elem constraints.Ordered](...)
>
> After:
>
> func Filter[Elem interface{}](...)
> func Map[Elem1, Elem2 interface{}](...)
> func Max[Elem constraints.Ordered](...)
>
> "interface{}" may be a little bulky, especially it since it is usually 
> used for the simple cases. But if there was a short type alias for 
> "interface{}" like "any" it can look good:
>
> type any = interface{}
>
> func Filter[Elem any](...)
> func Map[Elem1, Elem2 any](...)
> func Max[Elem constraints.Ordered](...)
>
>

-- 
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/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%40googlegroups.com.

[go-nuts] [generics] Feedback on optional type keyword experiment

['Carla Pfaff' via golang-nuts]

I just discovered the experiment to make the "type" keyword optional in 
certain cases on the dev.go2go branch. The commit message says:

---
Experiment: Make "type" keyword optional in generic type declarations 
when
it is clear that we can't have an array type declaration. This is the 
case
when we have one the following:

- more than one type parameter
- a type parameter with a constraint
- a trailing comma in the type parameter list
--

If the "type" keyword is not necessary if a constraint is present, then why 
not make a constraint mandatory and get rid of the "type" keyword in type 
parameter lists altogether?

Before:

func Filter[type Elem](...)
func Map[Elem1, Elem2](...)
func Max[Elem constraints.Ordered](...)

After:

func Filter[Elem interface{}](...)
func Map[Elem1, Elem2 interface{}](...)
func Max[Elem constraints.Ordered](...)

"interface{}" may be a little bulky, especially it since it is usually used 
for the simple cases. But if there was a short type alias for "interface{}" 
like "any" it can look good:

type any = interface{}

func Filter[Elem any](...)
func Map[Elem1, Elem2 any](...)
func Max[Elem constraints.Ordered](...)

-- 
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/5082eaaf-016b-4826-b31b-0dd67724ab77n%40googlegroups.com.

[go-nuts] Re: [generics] Fuzzer, Type Switches

['Carla Pfaff' via golang-nuts]

Why not write two functions?

On Friday, 17 July 2020 at 21:36:38 UTC+2 jrh...@gmail.com wrote:

> I was playing around with trying to use generics to de-interface-ify a 
> fuzzer implementation, and I ran into some stumbling blocks.
>
> is it possible to perform type switches? It seems the answer is currently 
> no (example , design doc 
> reference 
> ).
>  
> Maybe there's a better way to handle the following?
>
> type Primitive interface {
>   type int, string
> }
>
> func Randomize(type F Primitive)(f F, r *rand.Rand) F {
>   switch v := (interface{})(f).(type) {
>   case string:
> return fmt.Sprintf("%s--%d", v, r.Int())
>   case int:
> return v + r.Int()
>   default:
> panic(fmt.Sprintf("I don't know about type %T!\n", v))
>   }
> }
>
> func main() {
>   r := rand.New(rand.NewSource(1))
>   fmt.Println(Randomize(int)(1, r))
> }
>
> Thanks,
> Josh
>
>

-- 
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/c4c0c308-bd05-48eb-aa60-bcbcc2932399n%40googlegroups.com.

Re: [go-nuts] Re: Generics and parentheses

['Carla Pfaff' via golang-nuts]

On Thursday, 16 July 2020 at 22:44:21 UTC+2 jpap wrote:

> I don't think [[T]] is offensive to the surrounding code, and would love 
> to know what more people think.
>

It becomes even worse once you nest generic types:

MyMap[[string, MyList[[int
 

-- 
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/e3a55215-7f51-4a51-b6f4-6861fc0b5e40n%40googlegroups.com.

Re: [go-nuts] Re: Generics and parentheses

['Carla Pfaff' via golang-nuts]

Generics are not the most important part of the language/code. Let's not 
make them stick out like a sore thumb.
On Thursday, 16 July 2020 at 22:12:17 UTC+2 jpap wrote:

> On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote:
>
>> On Thu, Jul 16, 2020 at 12:41 PM joshua harr  wrote: 
>> > Just a note on your rationale for why not to use <: :> : 
>> > "... requires more typing." Golang has, rather famously, never shied 
>> away from making developers type more. The reason it hasn't, as far as I 
>> understand, is that code is read far often than it is written, and so the 
>> extra verbosity is worth the ease in reading the code. IMHO, that principle 
>> very much applies here. The *readability* of the syntax should be a far 
>> more important consideration than whether there is an extra character in 
>> the syntax. 
>>
>> That's a fair point. Having two characters is still in my mind a 
>> disadvantage, but I agree that that disadvantage could be outweighed 
>> by a gain in readability. 
>>
>> That said, personally I don't find <:T:> to be any more (or less) 
>> readable than [T]. 
>>
>> Ian 
>>
>
> I agree that readability should be a big consideration.
>
> The problem with [T] is that you need to actively read the surrounding 
> code to discern between a possible array access or type parameter.  I would 
> prefer it to be immediately obvious so that visually scanning through code 
> is as fast and clear as can be.
>
> An alternative syntax to [T] that could enable "quick looks" is [[T]].  It 
> would be nice to use <>, but that has parsing ambiguities with the 
> existing bit-shift operator, just as  is ambiguous with the comparison 
> operator.
>
> The burden of typing the same character twice on a keyboard in quick 
> succession for [[T]] is more or less the same as the single-character 
> version [T] and less so than two-character delimiters like <: and :>, and 
> especially those delimiters that require the shift-key in play at the same 
> time.
>
> jpap
>
>

-- 
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/8f7562b2-0262-4c3b-8659-d86bc7bba0dan%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

['Carla Pfaff' via golang-nuts]

I really like this square bracket syntax and I'm glad that Go does not 
repeat the mistakes other languages have made..

-- 
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/3d2d6b20-4804-4475-957b-0390511c47f8n%40googlegroups.com.

[go-nuts] Re: go.pkg.dev: blitznote.com/src/semver doesn't show up

['Carla Pfaff' via golang-nuts]

For me it is in the search results. Currently on page 5, fifth entry:
https://pkg.go.dev/search?page=5=semver

On Friday, 26 June 2020 at 21:47:30 UTC+2 Mark Kubacki wrote:

> Hi,
>
> I've noticed my package, blitznote.com/src/semver, doesn't show up in 
> pkg.go.dev despite having been licensed under one of the blessed 
> licenses, being some months old, and having been pulled several times using 
> the default proxy.
>
> Specifically, searching for “semver” won't produce it, even though after 
> some pages search results are no longer original code (but forks, 
> vendorings).
>
> Going directly through 
> https://pkg.go.dev/blitznote.com/src/semver/v3?tab=doc will work.
>
> Where can I find the requirements for having it (and other modules of 
> mine) included in search results?
>
> Thanks, Mark
>

-- 
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/50fa635e-b029-4a48-94f1-29cd705f080fn%40googlegroups.com.