Re: [go-nuts] Re: raw bit types without arithmetic

By the way - I definitely don't feel strongly about this, and I am just guessing that it's more likely to support new operators for existing types than it is to create new built-in types. I think bitsN types are fine, although again I don't know if I'd personally ever use them. But I am enjoyin

Re: [go-nuts] generics question

Sorry for the noise - looks like you meant when passing around objects by this type, not just creating objects. On Friday, May 3, 2024 at 11:02:37 AM UTC-6 Kevin Chowski wrote: > If you are just unhappy about the A and A* while using a literal for C: > note that if you are willing/able to write

Re: [go-nuts] generics question

If you are just unhappy about the A and A* while using a literal for C: note that if you are willing/able to write a wrapper function instead of using a literal, type inference works well today: func NewC[E any, P Settable[E]](val []E) C[E, P] { return C[E, P]{Val: val} } var c = NewC([]A{1, 2,

Re: [go-nuts] Is it possible to "extract" the generic [T] from a reflected type ?

If I understand correctly, the restriction is that the compiler has to know all possible instantiations of a generic func/type/etc at compile time. So listing out each specific Hello instantiation is the workaround, which allows you to approximate this if you have a closed set of types you want

Re: [go-nuts] WebAssembly and Filesystem access

Fri, Nov 04, 2022 at 02:08:08PM -0700, 'Kevin Chowski' via golang-nuts > wrote: > > [...] > > I am on a project which primarily ships a Go command line interface > (CLI), > > but we have aspirations of using the wasm compilation mode to also > > dist

[go-nuts] WebAssembly and Filesystem access

Hey all, I couldn't find a prior thread or other information on the web after a bit of searching, but if this is answered elsewhere I'd appreciate a link to follow. I am on a project which primarily ships a Go command line interface (CLI), but we have aspirations of using the wasm compilation

[go-nuts] Re: Error-checking with errors.As() is brittle with regards to plain vs pointer types

If some func advertises the type of error it returns, it should mention the precise type. That is, if a function returns *ABC in error conditions, it should document that it returns *ABC (not ABC, that is a different type). Why is that no sufficient? An API already must document the type of erro

[go-nuts] Re: Better replacement for strings.Title?

Someone replied off-list and suggested using the cases.NoLower option while initializing the Caser. And it worked! Thanks! On Wednesday, March 30, 2022 at 10:15:40 AM UTC-6 Kevin Chowski wrote: > I guess "Better" is not really what I mean... maybe more accurately I need > something "closer" to

[go-nuts] Re: Better replacement for strings.Title?

I guess "Better" is not really what I mean... maybe more accurately I need something "closer" to strings.Title. On Wednesday, March 30, 2022 at 9:59:24 AM UTC-6 Kevin Chowski wrote: > strings.Title is newly deprecated >

[go-nuts] Better replacement for strings.Title?

strings.Title is newly deprecated

[go-nuts] Re: Goroutines - handles, signals, and signal handlers

In Go, goroutines are meant to explicitly signal each other; further, it seems very intentional that goroutines are never interrupted in the middle of execution like an interrupt service routine might in a lower-level situation. It was mentioned in a prior message a bit, but to add more details

[go-nuts] Re: Trouble exporting function with anonymous struct containing anonymous fields as parameter

Sorry, I included a typo. I have edited my reply below to fix it. On Tuesday, November 16, 2021 at 8:25:47 PM UTC-7 Kevin Chowski wrote: > It's not clear to me what problem you are solving. Can you clarify *why* > you want to do this? > > For what it's worth, this seems correct to me: a function

[go-nuts] Re: Trouble exporting function with anonymous struct containing anonymous fields as parameter

It's not clear to me what problem you are solving. Can you clarify *why* you want to do this? For what it's worth, this seems correct to me: a function defined in package X should not be able to access the unexported fields of a struct in package Y. If you embed a 'byte' into a struct, that is

[go-nuts] Re: %v for []string{} and []string{""}

The "%#v" print verb is intended to be used for unambiguous printing of a type, but that means it will have a prefix of `[]string` in order to ensure the type is unambiguous. I personally use %q a lot any time I know I have a string (or set of strings) which might be ambiguous in some way, but I

[go-nuts] Re: embed.FS and memory limitations

If you had a simple test program or microbenchmark which put some numbers behind your concerns, I think you'll get a bit more traction. Have you tried to measure the effect of page faults on reading data from embedded files (or, I guess, any sort of data that has fallen out of the pagecache)? I

Re: [go-nuts] Can we "go get" unreleased standard library packages?

To follow up on Axel's suggestion to use "tip", this tool will automatically download the latest repository and compile it for you, with just two simple commands (download/compile the tool with go get, then run the tool): https://godoc.org/golang.org/dl/gotip I used it the other week and I was

Re: [go-nuts] Alignment requirements for 64-bit atomics on 386

ss I missed the obvious "x86" in there; my brain saw "ARM 32 32-bit MIPS" and misread it as "32-bit ARM and 32-bit MIPS". My mistake for sure. Thanks again, Kevin On Friday, November 20, 2020 at 1:54:28 PM UTC-7 Ian Lance Taylor wrote: > On Fri, Nov 20,

[go-nuts] Alignment requirements for 64-bit atomics on 386

I am debugging an issue in which we are seeing a crash on an atomic access; on go 1.14.7 and 1.15.2 this reproduces with the following error: > panic: runtime error: invalid memory address or nil pointer dereference > [signal S

[go-nuts] Re: How does the Golang compiler handle dependencies?

C/C++ also has object file caching (depending on how your build is set up, I guess). In C/C++ the issue is that you need to possibly open a large number of header files when you import any header file. For example, if I write a file "main.c" which imports "something.h", which in turn imports "a

[go-nuts] Re: handling constant of maps

I would do (and have done) what you suggested in your last example, but just put the codes into a 'var' block as opposed to a const block, e.g.: var ( >E270_01 = ErrorCode{"270.01", "this is error description"} ) I would not personally be concerned about people modifying that public value

Re: [go-nuts] Deleting map entry from the top level of a nested map doesn't clean the underlying memory

Guessing based on your latest description: are you aware that there is no partial slice collection in GC? That is: > bigSlice := make([]int, 1000*1000) subSlice := bigSlice[0:1:1] bigSlice = nil runtime.GC() // At this point, bigSlice is still allocated! It cannot be freed by the GC > (i

[go-nuts] Re: escape analysis question

Slightly more minimal, in my testing it seems that the call to 'nothing' is not needed. I do not quite know why, but these two lines seem to show how the compiler is reasoning about this escape: escape.go:4:11: flow: {heap} = x: escape.go:4:11: from *y = x (assign) at escape.go:6:5 I do

Re: [go-nuts] How to pass http.ResponseWriter while writing test case in Go

Agreed - attempting to obtain 100% test coverage with only small-scale tests is not always the best usage of engineering time. Not just writing it the first time, but taking into account maintenance as well. On Monday, April 1, 2019 at 12:07:03 PM UTC-7, Robert Engels wrote: > > I wouldn’t test