>
>> I think the general rule of thumb I find agreeable is "the length of
>an
>> identifier should be inversely correlated to the distance between its
>> declaration and its use".
>>
>
Loosely correlated, perhaps.
I'll be honest. I have always found this advice to be rarely useful. It
certainl
Hi Drew,
Quoth Drew DeVault:
> With the help of some volunteers, we have already made modest,
> conservative improvements to godoc.org. Some features have been
> updated to work with JavaScript disabled, dead links and obsolete tools
> have been pruned, and our fork should be easier to use on your
On Wed, Jan 20, 2021 at 4:22 PM atd...@gmail.com wrote:
> It' has probably been discussed somewhere but I am curious about what
> might have been the issues when considering an implementation of generics
> that would parameterized packages?
>
>
You can take a look at Standard ML / Ocaml "functors
Looking briefly, seems interesting but slightly different. It seems that
the intent described in the paper is to endorse full blown functions as a
replacement to import statements.
It is useful insofar that it could rationalize the use of build constraints
in Go. But it is too expressive in tha
Hi all,
Recently, I found myself fishing for this capability. My use case was, in
an earlier PR, I wrote up a code like this
```
func foo(bar *typ) bool {
bar.mutex.RLock()
*defer bar.mutex.RLock() /*/ use bar.attributes in a read only mode and
compute a bool value
}
```
This was an
Hi,
I am using Go 1.15 on Ubuntu 18.04
I am learning about cgo via the following tutorial
https://golang.org/cmd/cgo/
I have the following two files which I am able to run via
go run cgo_main.go
Knowing that it runs, I'd like to build it into an executable but I get
the fol
On Thu, Jan 21, 2021 at 10:21 PM Nicholas Yue wrote:
>
> /*
> #include "hello.c"
> */
> import "C"
Doing a #include of "hello.c" is unusual. That is most likely your
problem. The comment before the import "C" is handled as C code. C
code rarely does a #include of a .c file. Normally one does
