Should it be
interface{ int | any } // no specific types (intersection is empty)
instead
On Wednesday, January 5, 2022 at 11:20:16 PM UTC+8 tapi...@gmail.com wrote:
> https://tip.golang.org/ref/spec#Structure_of_interfaces
>
>interface{ int; any } // no specific types (intersection is
I think the build constraints works with directory names like *'windows'*
and *'unix', *tags like *`// +build windows`* or even the source code
file name with postfix like *'abc_windows.go' . *All works the same like
the build tags.
So if you build your package on linux for Windows it will com
https://tip.golang.org/ref/spec#Structure_of_interfaces
interface{ int; any } // no specific types (intersection is empty)
Why the constraint has no specific types. Doesn't it specify int?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
On Wed, Jan 5, 2022 at 11:32 AM Brieuc Jeunhomme wrote:
>
> So:
> $ cat mypackage.go
> package mypackage
>
> import "something/something/foo"
>
> func MyFunction() {
> some code
> some code
> some code
> foo.Bar(make(chan foo.Baz), make(chan foo.Foobar))
> }
>
> Is the code I would r
On Wed, Jan 5, 2022 at 11:32 AM Brieuc Jeunhomme
wrote:
> So:
> $ cat mypackage.go
> package mypackage
>
> import "something/something/foo"
>
> func MyFunction() {
> some code
> some code
> some code
> foo.Bar(make(chan foo.Baz), make(chan foo.Foobar))
> }
>
> Is the code I would re
I'm also confused.
On Wed, Jan 5, 2022 at 11:09 AM Brieuc Jeunhomme
wrote:
> For example, let's say you want to unit test MyFunction, which calls
> foo.Bar(chan foo.Baz, chan foo.Foobar) and foo compiles only under a single
> OS. If you want to write a portable unit test for MyFunction, you can
So:
$ cat mypackage.go
package mypackage
import "something/something/foo"
func MyFunction() {
some code
some code
some code
foo.Bar(make(chan foo.Baz), make(chan foo.Foobar))
}
Is the code I would really like to write.
foo has build constraints. As you can see, my code doesn't, i
On Wed, Jan 5, 2022 at 11:09 AM Brieuc Jeunhomme wrote:
> But here ,since under non-windows platforms, I can't import the package, it
> means I have to define wrappers for everything I use: types, constants,
> functions.
I don't get it. Put the common code in a file/in files with no build
cons
Yes, that's what I wanted to do, but it looks very tedious at best. In
"normal" unit tests, it's simple: import the package you're using, inject
its functions, reuse its types and constants.
But here ,since under non-windows platforms, I can't import the package, it
means I have to define wrap
