Re: [go-nuts] gofmt: expected declaration, found ')'

[Andreas Götz]

Forgive me. I have overlooked the fact, that this is a generated file that 
gets regenerated on the CI. Only in this case it must not since the 
generator does not cover a specific case and needs manual touch-up, hence 
must not be modified afterwrds.

Sorry for the noise and wish you a nice Sunday!

On Sunday, April 16, 2023 at 1:02:31 PM UTC+2 Jan Mercl wrote:

> On Sun, Apr 16, 2023 at 12:51 PM Andreas Götz  wrote:
>
> > Isn't gofmt ist part of the go command? Go ist the latest version:
>
> It is but it's a separate binary/executable file. Go version is one thing, 
> the version of the binary file that is actually executed when '$ gofmt' is 
> invoked is another thing, not necessarily related for many possible 
> reasons, like alias, $PATH etc.
>
> Try to check by issuing something like:
>
> jnml@3900x:~$ go version -m $(which gofmt)
> /home/jnml/bin/gofmt: go1.18.5
> path cmd/gofmt
> jnml@3900x:~$
>
>

-- 
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/1615d394-b9c5-4990-a338-76e9576e790an%40googlegroups.com.

Re: [go-nuts] gofmt: expected declaration, found ')'

[Jan Mercl]

On Sun, Apr 16, 2023 at 12:51 PM Andreas Götz 
wrote:

> Isn't gofmt ist part of the go command? Go ist the latest version:

It is but it's a separate binary/executable file. Go version is one thing,
the version of the binary file that is actually executed when '$ gofmt' is
invoked is another thing, not necessarily related for many possible
reasons, like alias, $PATH etc.

Try to check by issuing something like:

jnml@3900x:~$ go version -m $(which gofmt)
/home/jnml/bin/gofmt: go1.18.5
path cmd/gofmt
jnml@3900x:~$

-- 
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/CAA40n-UTurST8w%2BammqS6-6KGt0JQQych_skWEpyy7rSFmdmAw%40mail.gmail.com.

Re: [go-nuts] gofmt: expected declaration, found ')'

[Andreas Götz]

Isn't gofmt ist part of the go command? Go ist the latest version:

Setup
 
go version spec ^1.20 
Found
 
in cache @ /opt/hostedtoolcache/go/1.20.3/x64 
Added
 
go to the path 
Successfully
 
set up Go version ^1.20 
/opt/hostedtoolcache/go/1.20.3/x64/bin/go
 
env GOMODCACHE 
/opt/hostedtoolcache/go/1.20.3/x64/bin/go
 
env GOCACHE 
/home/runner/go/pkg/mod
 

/home/runner/.cache/go-build
 

Received
 
6992475 of 6992475 (100.0%), 10.2 MBs/sec 
Cache
 
Size: ~7 MB (6992475 B) 
/usr/bin/tar
 
-z -xf 
/home/runner/work/_temp/e939bf11-065d-4635-b10d-f083acd759cc/cache.tgz -P 
-C /home/runner/work/evcc/evcc 
Cache
 
restored successfully 
Cache
 
restored from key: 
setup-go-Linux-go-1.20.3-bb2ad7483b6059140940174a6d0146cd74cffa8dfe8f7aab3d2c995468e83809
 

go
 
version go1.20.3 linux/amd64


On Sunday, April 16, 2023 at 12:44:24 PM UTC+2 Axel Wagner wrote:

> I can't tell what version of gofmt is used? It does not seem to be 
> manually installed, so I assume it is the one that comes with the image. Is 
> it possible that's too old? I don't know why that would matter here, 
> though, the code doesn't seem to be using any new language features.
>
> On Sun, Apr 16, 2023 at 12:34 PM Andreas Götz  wrote:
>
>> The entire file is 
>> https://raw.githubusercontent.com/evcc-io/evcc/a5f7bb0100c4427a2f611f82b742f56a449681de/charger/keba-modbus_decorators.go,
>>  
>> part of https://github.com/evcc-io/evcc/pull/7485.
>>
>> Seems entirely find to me and works locally which makes it so confusing. 
>> Also formats fine: https://go.dev/play/p/XhoSAFjpGXa 
>>
>> On Sunday, April 16, 2023 at 12:31:22 PM UTC+2 Jan Mercl wrote:
>>
>>> On Sun, Apr 16, 2023 at 12:17 PM Andreas Götz  
>>> wrote: 
>>> > 
>>> > Good morning. Please excuse me for asking here- I'm stuck with 
>>> something that looks like a gofmt bug though that seems very unlikely. 
>>> > 
>>> > In CI (
>>> https://github.com/evcc-io/evcc/actions/runs/4712710735/jobs/8357929411?pr=7485)
>>>  
>>> I'm using a "porcelain" step to make sure only go-fmt'ed sources are 
>>> checked in: 
>>> > 
>>> > gofmt -w -l $(find . -name '*.go') 
>>> > 
>>> > This step fails with: expected declaration, found ')' on this line 
>>> which seems lengthy but perfectly valid: 
>>> > 
>>> > func decorateKeba(base *Keba, meter func() (float64, error), 
>>> meterEnergy func() (float64, error), phaseCurrents func() (float64, 
>>> float64, float64, error), phaseVoltages func() (float64, float64, float64, 
>>> error), phaseSwitcher func(int) error) api.Charger { 
>>> > ... 
>>> > } 
>>> > 
>>> > Funny enough, the error happens on CI only. I've recently noticed that 
>>> Go issues had identified and fixed a mis-compile error and I'm wondering if 
>>> that (or similar) might be hitting here due to wrong binary code? 
>>> > 
>>> > Any thoughts? 
>>>
>>> It's not enough to show the place of error, the preceding context may 
>>> cause it. Can you provide the whole file? Your snippet formats just 
>>> fine: https://go.dev/play/p/3GqFunldeq0 
>>>
>> -- 
>> 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/0dd15d6e-a01c-4815-a09c-9970e0f78b32n%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 

Re: [go-nuts] gofmt: expected declaration, found ')'

['Axel Wagner' via golang-nuts]

I can't tell what version of gofmt is used? It does not seem to be manually
installed, so I assume it is the one that comes with the image. Is it
possible that's too old? I don't know why that would matter here, though,
the code doesn't seem to be using any new language features.

On Sun, Apr 16, 2023 at 12:34 PM Andreas Götz 
wrote:

> The entire file is
> https://raw.githubusercontent.com/evcc-io/evcc/a5f7bb0100c4427a2f611f82b742f56a449681de/charger/keba-modbus_decorators.go,
> part of https://github.com/evcc-io/evcc/pull/7485.
>
> Seems entirely find to me and works locally which makes it so confusing.
> Also formats fine: https://go.dev/play/p/XhoSAFjpGXa
>
> On Sunday, April 16, 2023 at 12:31:22 PM UTC+2 Jan Mercl wrote:
>
>> On Sun, Apr 16, 2023 at 12:17 PM Andreas Götz 
>> wrote:
>> >
>> > Good morning. Please excuse me for asking here- I'm stuck with
>> something that looks like a gofmt bug though that seems very unlikely.
>> >
>> > In CI (
>> https://github.com/evcc-io/evcc/actions/runs/4712710735/jobs/8357929411?pr=7485)
>> I'm using a "porcelain" step to make sure only go-fmt'ed sources are
>> checked in:
>> >
>> > gofmt -w -l $(find . -name '*.go')
>> >
>> > This step fails with: expected declaration, found ')' on this line
>> which seems lengthy but perfectly valid:
>> >
>> > func decorateKeba(base *Keba, meter func() (float64, error),
>> meterEnergy func() (float64, error), phaseCurrents func() (float64,
>> float64, float64, error), phaseVoltages func() (float64, float64, float64,
>> error), phaseSwitcher func(int) error) api.Charger {
>> > ...
>> > }
>> >
>> > Funny enough, the error happens on CI only. I've recently noticed that
>> Go issues had identified and fixed a mis-compile error and I'm wondering if
>> that (or similar) might be hitting here due to wrong binary code?
>> >
>> > Any thoughts?
>>
>> It's not enough to show the place of error, the preceding context may
>> cause it. Can you provide the whole file? Your snippet formats just
>> fine: https://go.dev/play/p/3GqFunldeq0
>>
> --
> 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/0dd15d6e-a01c-4815-a09c-9970e0f78b32n%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/CAEkBMfELZnSujM6D7%2BNuXTYHP4QoFrOL7nD7rBUOp7pydEm7WQ%40mail.gmail.com.

Re: [go-nuts] gofmt: expected declaration, found ')'

[Andreas Götz]

The entire file 
is 
https://raw.githubusercontent.com/evcc-io/evcc/a5f7bb0100c4427a2f611f82b742f56a449681de/charger/keba-modbus_decorators.go,
 
part of https://github.com/evcc-io/evcc/pull/7485.

Seems entirely find to me and works locally which makes it so confusing. 
Also formats fine: https://go.dev/play/p/XhoSAFjpGXa 

On Sunday, April 16, 2023 at 12:31:22 PM UTC+2 Jan Mercl wrote:

> On Sun, Apr 16, 2023 at 12:17 PM Andreas Götz  wrote:
> >
> > Good morning. Please excuse me for asking here- I'm stuck with something 
> that looks like a gofmt bug though that seems very unlikely.
> >
> > In CI (
> https://github.com/evcc-io/evcc/actions/runs/4712710735/jobs/8357929411?pr=7485)
>  
> I'm using a "porcelain" step to make sure only go-fmt'ed sources are 
> checked in:
> >
> > gofmt -w -l $(find . -name '*.go')
> >
> > This step fails with: expected declaration, found ')' on this line which 
> seems lengthy but perfectly valid:
> >
> > func decorateKeba(base *Keba, meter func() (float64, error), meterEnergy 
> func() (float64, error), phaseCurrents func() (float64, float64, float64, 
> error), phaseVoltages func() (float64, float64, float64, error), 
> phaseSwitcher func(int) error) api.Charger {
> > ...
> > }
> >
> > Funny enough, the error happens on CI only. I've recently noticed that 
> Go issues had identified and fixed a mis-compile error and I'm wondering if 
> that (or similar) might be hitting here due to wrong binary code?
> >
> > Any thoughts?
>
> It's not enough to show the place of error, the preceding context may
> cause it. Can you provide the whole file? Your snippet formats just
> fine: https://go.dev/play/p/3GqFunldeq0
>

-- 
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/0dd15d6e-a01c-4815-a09c-9970e0f78b32n%40googlegroups.com.

Re: [go-nuts] gofmt: expected declaration, found ')'

[Jan Mercl]

On Sun, Apr 16, 2023 at 12:17 PM Andreas Götz  wrote:
>
> Good morning. Please excuse me for asking here- I'm stuck with something that 
> looks like a gofmt bug though that seems very unlikely.
>
> In CI 
> (https://github.com/evcc-io/evcc/actions/runs/4712710735/jobs/8357929411?pr=7485)
>  I'm using a "porcelain" step to make sure only go-fmt'ed sources are checked 
> in:
>
> gofmt -w -l $(find . -name '*.go')
>
> This step fails with: expected declaration, found ')' on this line which 
> seems lengthy but perfectly valid:
>
> func decorateKeba(base *Keba, meter func() (float64, error), meterEnergy 
> func() (float64, error), phaseCurrents func() (float64, float64, float64, 
> error), phaseVoltages func() (float64, float64, float64, error), 
> phaseSwitcher func(int) error) api.Charger {
> ...
> }
>
> Funny enough, the error happens on CI only. I've recently noticed that Go 
> issues had identified and fixed a mis-compile error and I'm wondering if that 
> (or similar) might be hitting here due to wrong binary code?
>
> Any thoughts?

It's not enough to show the place of error, the preceding context may
cause it. Can you provide the whole file? Your snippet formats just
fine: https://go.dev/play/p/3GqFunldeq0

-- 
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/CAA40n-XdrYSV-jkr%2BWBvz8Gd81uAqgr0%2Bp9dZoycBJppOwz88w%40mail.gmail.com.

[go-nuts] gofmt: expected declaration, found ')'

[Andreas Götz]

Good morning. Please excuse me for asking here- I'm stuck with something 
that looks like a gofmt bug though that seems very unlikely.

In CI 
(https://github.com/evcc-io/evcc/actions/runs/4712710735/jobs/8357929411?pr=7485)
 
I'm using a "porcelain" step to make sure only go-fmt'ed sources are 
checked in:

gofmt -w -l $(find . -name '*.go')

This step fails with: expected declaration, found ')' on this line which 
seems lengthy but perfectly valid:

func decorateKeba(base *Keba, meter func() (float64, error), meterEnergy 
func() (float64, error), phaseCurrents func() (float64, float64, float64, 
error), phaseVoltages func() (float64, float64, float64, error), 
phaseSwitcher func(int) error) api.Charger {
...
}

Funny enough, the error happens on CI only. I've recently noticed that Go 
issues had identified and fixed a mis-compile error and I'm wondering if 
that (or similar) might be hitting here due to wrong binary code?

Any thoughts?

-- 
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/e68c6569-3e62-4ef4-9d3a-eaa8598601e3n%40googlegroups.com.

Re: [go-nuts] Re: Pointer constraint to generics

[Jan]

I think I see your point now, thanks for explaining. You are right, I 
should avoid having this sense of "type security". The `Pointer[]` library 
is only doing syntatic sugar around the fundamentally unsafe casting of an 
`unsafe.Pointer`.

Having said that, unfortunately limiting it to a list of types in 
`CPointer` also doesn't solve the problem, because one could still choose 
the wrong one.



On Sunday, April 16, 2023 at 9:44:52 AM UTC+2 Axel Wagner wrote:

> The thing is, if it works with an arbitrary pointer type, it also works 
> with `*[1<<30]byte`, giving unsafe memory access to essentially the entire 
> memory space. Without any additional safeguards. You say it would "feel 
> cleaner without the additional lines of unsafe.Pointer floating around", 
> but that feeling is treacherous. Returning an unsafe.Pointer is honest and 
> clear, because it really *is* an unsafe operation. And adding generics to 
> the mix just gives off the false impression that you have a type-checked 
> operation, when you don't.
>
> I really think the right solution here is to provide wrappers that just 
> provide type-safe access to the underlying C calls. But you do you, of 
> course.
>
> On Sun, Apr 16, 2023 at 7:59 AM Jan  wrote:
>
>> Thanks for the suggestions Alex. Interesting that enumerating the 
>> pointers in a constraint would work ... but it makes sense.
>>
>> I think I disagree with the statement about not wanting to allow any 
>> pointer type. From my project perspective there will be indeed a limited 
>> number of those (~10).  But from the `PointerOrError` library (my StatusOr 
>> library) perspective, I think it shouldn't know which pointers it's being 
>> used for (or need to include every ".h" file I have). Ideally it would 
>> support arbitrary pointer type that a client of the library might want to 
>> use. 
>>
>> Again ... not a big issue I can simply use the UnsafePointerOrError 
>> version, and cast to the desired pointer at the next line. It's just would 
>> feel clearner with one fewer line with a floating unsafe pointer around :)
>>
>> cheers 
>>
>> On Saturday, April 15, 2023 at 10:54:47 PM UTC+2 Axel Wagner wrote:
>>
>>> I guess thinking about some more, I don't really understand the point of 
>>> what you're doing. It seems you *can* actually get the static guarantee you 
>>> want - you just have to spell the call 
>>> `(*C.mystruct)(UnsafePointerOrError(s))` instead of 
>>> `PointerOrError[C.mystruct](s)`. If you *could* restrict the type parameter 
>>> to be "any pointer", the two would actually be entirely equivalent, giving 
>>> you exactly the same guarantees.
>>>
>>> I think in reality you *don't* want to allow "any pointer type". I think 
>>> in reality you want the type to be dependent on the C++ function you are 
>>> calling - which returns the Status. I don't think you can use templated C++ 
>>> types, otherwise you would probably want to do something like
>>> func Call[T any](f func(…) C.StatusOr) (T, error)
>>>
>>> In the absence of that, you might try listing the types which are valid:
>>> type CPointer interface{
>>> *C.MyStruct | *C.MyOtherStruct | *C.YourStruct
>>> }
>>> func PointerOrError[T CPointer](s C.StatusOr) (T, error) { … }
>>>
>>>
>>>
>>> On Sat, Apr 15, 2023 at 10:24 PM Axel Wagner  
>>> wrote:
>>>
 You should be able to instantiate the function using a Pointer. That 
 is, you can write

 func PointerOrError[T any](s C.StatusOr) (t T, err error) {
 var ptr unsafe.Pointer
 ptr, err = UnsafePointerOrError(s) // <-- unsafe.Pointer, error
 if err != nil {
 return
 }
 return *(*T)(unsafe.Pointer(&ptr))
 }

 func main() {
 var s C.StatusOr
 p := PointerOrError[*C.mystruct](s)
 _ = p
 }

 It's unfortunate, of course, that this would allow you to instantiate 
 the function using a non-pointer as well, but it seems that's impossible 
 to 
 prevent statically? You can catch it dynamically by doing something akin to

 if k := reflect.TypeOf(*new(T)).Kind(); k != reflect.Pointer && k != 
 reflect.UnsafePointer {
 panic("PointerOrError must be instantiated with pointer type")
 }

 Obviously, none of this is ideal, but maybe it's the best you can do - 
 apart from generating code.

 On Sat, Apr 15, 2023 at 8:48 PM Jan  wrote:

> Re-factoring your example to use CGO, in a small main.go file:
>
> ```
> $ go run .
> ./main.go:28:10: cannot use incomplete (or unallocatable) type as a 
> type argument: main._Ctype_struct_MyThing
> $ cat main.go 
> package main
>
> // struct MyThing;
> // typedef struct MyThing MyThing;
> import "C"
> import (
> "fmt"
> "unsafe"
> )
> import "flag"
>
> func PointerOrError[T *Q, Q any](s int) (t T, err error) {
> var ptr unsafe.Pointer
>   

[go-nuts] Re: cgo Compiling C files housed in different directory than Go files

[Palash Bauri]

I have made it work, by putting a go file in every child directory.

https://github.com/bauripalash/cpank

--
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/f73b798f-66f7-4853-ac8a-ba33e398fbed%40gmail.com.

Re: [go-nuts] Re: Pointer constraint to generics

['Axel Wagner' via golang-nuts]

The thing is, if it works with an arbitrary pointer type, it also works
with `*[1<<30]byte`, giving unsafe memory access to essentially the entire
memory space. Without any additional safeguards. You say it would "feel
cleaner without the additional lines of unsafe.Pointer floating around",
but that feeling is treacherous. Returning an unsafe.Pointer is honest and
clear, because it really *is* an unsafe operation. And adding generics to
the mix just gives off the false impression that you have a type-checked
operation, when you don't.

I really think the right solution here is to provide wrappers that just
provide type-safe access to the underlying C calls. But you do you, of
course.

On Sun, Apr 16, 2023 at 7:59 AM Jan  wrote:

> Thanks for the suggestions Alex. Interesting that enumerating the pointers
> in a constraint would work ... but it makes sense.
>
> I think I disagree with the statement about not wanting to allow any
> pointer type. From my project perspective there will be indeed a limited
> number of those (~10).  But from the `PointerOrError` library (my StatusOr
> library) perspective, I think it shouldn't know which pointers it's being
> used for (or need to include every ".h" file I have). Ideally it would
> support arbitrary pointer type that a client of the library might want to
> use.
>
> Again ... not a big issue I can simply use the UnsafePointerOrError
> version, and cast to the desired pointer at the next line. It's just would
> feel clearner with one fewer line with a floating unsafe pointer around :)
>
> cheers
>
> On Saturday, April 15, 2023 at 10:54:47 PM UTC+2 Axel Wagner wrote:
>
>> I guess thinking about some more, I don't really understand the point of
>> what you're doing. It seems you *can* actually get the static guarantee you
>> want - you just have to spell the call
>> `(*C.mystruct)(UnsafePointerOrError(s))` instead of
>> `PointerOrError[C.mystruct](s)`. If you *could* restrict the type parameter
>> to be "any pointer", the two would actually be entirely equivalent, giving
>> you exactly the same guarantees.
>>
>> I think in reality you *don't* want to allow "any pointer type". I think
>> in reality you want the type to be dependent on the C++ function you are
>> calling - which returns the Status. I don't think you can use templated C++
>> types, otherwise you would probably want to do something like
>> func Call[T any](f func(…) C.StatusOr) (T, error)
>>
>> In the absence of that, you might try listing the types which are valid:
>> type CPointer interface{
>> *C.MyStruct | *C.MyOtherStruct | *C.YourStruct
>> }
>> func PointerOrError[T CPointer](s C.StatusOr) (T, error) { … }
>>
>>
>>
>> On Sat, Apr 15, 2023 at 10:24 PM Axel Wagner 
>> wrote:
>>
>>> You should be able to instantiate the function using a Pointer. That is,
>>> you can write
>>>
>>> func PointerOrError[T any](s C.StatusOr) (t T, err error) {
>>> var ptr unsafe.Pointer
>>> ptr, err = UnsafePointerOrError(s) // <-- unsafe.Pointer, error
>>> if err != nil {
>>> return
>>> }
>>> return *(*T)(unsafe.Pointer(&ptr))
>>> }
>>>
>>> func main() {
>>> var s C.StatusOr
>>> p := PointerOrError[*C.mystruct](s)
>>> _ = p
>>> }
>>>
>>> It's unfortunate, of course, that this would allow you to instantiate
>>> the function using a non-pointer as well, but it seems that's impossible to
>>> prevent statically? You can catch it dynamically by doing something akin to
>>>
>>> if k := reflect.TypeOf(*new(T)).Kind(); k != reflect.Pointer && k !=
>>> reflect.UnsafePointer {
>>> panic("PointerOrError must be instantiated with pointer type")
>>> }
>>>
>>> Obviously, none of this is ideal, but maybe it's the best you can do -
>>> apart from generating code.
>>>
>>> On Sat, Apr 15, 2023 at 8:48 PM Jan  wrote:
>>>
 Re-factoring your example to use CGO, in a small main.go file:

 ```
 $ go run .
 ./main.go:28:10: cannot use incomplete (or unallocatable) type as a
 type argument: main._Ctype_struct_MyThing
 $ cat main.go
 package main

 // struct MyThing;
 // typedef struct MyThing MyThing;
 import "C"
 import (
 "fmt"
 "unsafe"
 )
 import "flag"

 func PointerOrError[T *Q, Q any](s int) (t T, err error) {
 var ptr unsafe.Pointer
 ptr, err = UnsafePointerOrError(s) // <-- unsafe.Pointer, error
 if err != nil {
 return
 }
 t = (T)(ptr)
 return
 }

 func UnsafePointerOrError(v int) (unsafe.Pointer, error) {
 return unsafe.Pointer(&v), nil
 }

 func main() {
 flag.Parse()
 t, _ := PointerOrError[*C.MyThing](1)
 fmt.Println(t)
 }
 ```


 On Saturday, April 15, 2023 at 8:41:28 PM UTC+2 Jan wrote:

> Thanks! I hadn't realized that one could constraint T to be a pointer
> type by using