Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Thanks for all the replies. 

Unfortunately, as I found out today, including the `.a` (static libraries) 
in the Github just got to its limit (100Mb), so I don't think this is an 
option anymore :( I'm going to investigate the Gihtub LFS (Large File 
Storage), not sure how well it will integrate with `go get` though -- I've 
never used it before.

 Interesting to know that an empty Go package file is no longer needed to 
fetch a directory with binary dependencies (handy also for go:embed in 
cases where the binary files are on a separate directory).

Still for my Go library with a `.so` dependency I'm not sure yet what is 
the answer. I'm thinking about creating another tool that goes over all the 
dependencies of module, and automatically downloads release files to a 
configured directory ... so at least all one needs to do is execute one 
command and get all dependencies of all libraries installed. Any thoughts ?

@Mike Schinkel: the go:embed is used in a different context (when embedding 
blobs of binary). We need prebuilt binary libraries that will be 
linked with the Go code during compilation. Preferably something that will 
transparently work with `go get` / `go build` / `go install`.

cheers

On Tuesday, October 17, 2023 at 8:46:01 PM UTC+2 Justin Israel wrote:

> On Wednesday, October 18, 2023 at 3:12:29 AM UTC+13 Marc-Antoine Ruel 
> wrote:
>
> Sorry I wasn't clear. The static libraries are in a subdirectory because 
> the user should not care and these libraries are effectively third party 
> code.
>
>
> Actually, you were totally clear. Sorry if my comment didn't make sense. I 
> get that the user doesn't need to worry about the third_party directory 
> with the header and pre-built static libraries. And I saw how you arrange 
> to pick up the right ones in the code. My point was that from previous 
> experience, "go get" would prune away directories that do not contain go 
> source code, after it performs the clone from the remote, into the module 
> cache. So I would have expected that when someone uses your library as a 
> dependency, it would have omitted the needed third_party directory, for not 
> having any Go source files in it. But when I tested it just now, it does 
> seem to retain the subdirectory and link correctly. Maybe this was improved 
> as of recent Go releases. 
> In earlier versions of the Go tool, I would have either included a dummy 
> Go source file in the subdirectory, or just kept the non-go files in the 
> root with the rest of the Go source.
> Maybe someone else can clarify if this workflow has been improved?
>
>
> This declares the generic code available everywhere:
> https://github.com/periph/d2xx/blob/main/d2xx.go
>
> One set of files declare the import that is OS and CPU arch appropriate, 
> e.g. 
> https://github.com/periph/d2xx/blob/main/d2xx_linux_amd64.go
>
> Then another set of two files defines the OS specific code. In practice, 
> POSIX and windows;
> https://github.com/periph/d2xx/blob/main/d2xx_posix.go
> https://github.com/periph/d2xx/blob/main/d2xx_windows.go
>
> A CGO_ENABLED=0 build gets instead redirected to
> https://github.com/periph/d2xx/blob/main/d2xx_posix_no_cgo.go
> but not on windows because this package uses dynamic linking on windows. 
> Adapt as appropriate in your use case.
>
> I hope this helps.
>
> M-A
>
>
> Le lun. 16 oct. 2023, 21 h 13, Justin Israel  a 
> écrit :
>
>
>
> On Tuesday, October 17, 2023 at 10:40:33 AM UTC+13 Marc-Antoine Ruel wrote:
>
> I second Richard's suggestion. I used the same trick for 
> https://github.com/periph/d2xx. This git repository contains a minimalist 
> shim for the .a libraries and nothing else. It's designed to compile on any 
> platform. It falls back to a scaffolding if the corresponding .a library is 
> not present for the OS-arch combination or if CGO is disabled. It makes 
> testing easier.
>
> Then a proper package under https://github.com/periph/host/tree/main/ftdi 
> exposes a higher level abstraction for the user.
>
>
> With only headers and static libs in the thirdparty directory, is this 
> package "go-gettable"? 
> Will go make the subdirectory available in that case? It usually ignores 
> if there is no Go source files. 
>  
>
> M-A
>
> Le lun. 16 oct. 2023, à 14 h 48, Mike Schinkel  a 
> écrit :
>
> Hi Jan,
>
> I'm going to go out on a limb here and suggest looking at using Go's 
> `embed` feature?
>
> https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/
>
> I have not tried it with C libraries so there may be numerous reasons why 
> it may not work for your needs. For example, I do not know what is required 
> to *"install"* the libraries so that might be your sticking point that 
> embed would not address. But if building on the user's machine is the real 
> problem and you can distribute pre-build binaries then this might work for 
> you.  
>
> Basically Go reads a `//go:embed` comment, converts your files into Go 
> source code, compiles that code, and then provi

[go-nuts] recommended statistics package? Requirements: ANOVA, Brown-Forsythe

[王富民awaw]

Hi follow Gophers

I wonder is there a canonical, verifiably correct Go package for statistics?
In particular, Go code that does the Brown-Forsythe test of equal variance.
Ideally in pure Go, but linking with CGo is OK.

A search on Google and pkg.go.dev does not return helpful results.
I wonder is there anything that the community could share?

-- 
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/6431764c-b732-4dd4-8d0a-e69b43f51298n%40googlegroups.com.

Re: [go-nuts] Can we not invoke methods on types referring to generics?

['Axel Wagner' via golang-nuts]

FWIW I think what OP is ultimately asking about is some form of nominal
subtyping. When they say "automatic upcasting", they refer (I believe) to
what Go calls "assignability", which is in essence a subtype relationship.
So they want to be able to define a new type, that is a subtype of an
existing type, but add some methods to it.

And - controversially, perhaps - I don't think they would be anything
inherently wrong about it. Except that it means we'd have two ways to have
subtyping in the language.

First, I agree with other posters here that it would be bad if `type String
string` would create a subtype relationship between `String` and `string`.
Ultimately, we do want to have the ability to create genuinely new types,
with no relationship between them. It's an important safety mechanism. But
we could imagine having a new form of type declaration, say `type A < B`
(syntax only illustrative) that would create a new type `A`, which inherits
all methods from `B`, could add its own and which is assignable to `B` (but
not vice-versa). We basically would have three kinds of declarations: 1.
`type A B`, introducing no subtype relationship between `A` and `B`, 2.
`type A < B`, which makes `A` a subtype of `B` and 3. `type A = B`, which
makes them identical (and is conveniently equivalent to `A < B` and `B <
A`).

I think this would honestly be fine and perfectly safe. You'd still have to
explicitly declare that you want the new type to be a subtype, so you don't
get the weak typing of C/C++. And the subtype relationship would only
"flow" in one direction, so you can't *arbitrarily* mix them up.

Where difficulties would arise is that it naturally leads people to want to
subtype from *multiple* types. E.g. it would make sense wanting to do

type Quadrilateral [4]Point
func (Quadrilateral) Area() float64
type Rhombus < Quadrilateral
func (Rhombus) Angles() (float64, float64)
type Rectangle < Quadrilateral
func (Rectangle) Bounds() (min, max Point)
type Square < (Rhombus, Rectangle) // again, syntax only illustrative)

The issue this creates is that subtype relationships are transitive and in
this case would become *path-dependent*. `Square` is a subtype of
`Quadrilateral`, but it can get there either via `Rhombus` or via
`Rectangle` and it's not clear which way to get there. This matters if
`Rhombus` or `Rectangle` (or both) start overwriting methods of
`Quadrilateral`. The compiler needs to decide which method to call. Usually
it does that by defining some tie-breaks, e.g. "use the type named first in
the subtype declaration". But there is a lot of implicity there and with
deeper hierarchies, you can get spooky breakages at a distance, if some
type in the middle of the hierarchy does some seemingly harmless change
like overloading a method. Look up "Python Method Resolution Order" for the
kinds of problems that can arise.

Structural subtyping does not have these issues, because the subtype
relationship is completely determined by a subset relationship - in Go's
case, sets of methods of the dynamic type of the interface. And since it
can't override methods, there is no path-dependence - any two methods sets
uniquely determine a maximal common subset and a minimum common superset
and the path from any interface type to any other interface is unique
(structural subtyping is a Lattice
).

I think any kind of subtyping relationship *should* ultimately allow you to
have multiple super types - these kinds of hierarchies are just far too
common to ignore. For example, look at the `io` package - pretty much every
combination of `Reader`, `Writer` and `Closer` has some reasonable use
cases. I also think there are good technical reasons to avoid the
path-dependency pitfall. So it seems to me an easily defensible decision to
use structural subtyping as the primary form of subtype relationship, as it
allows you to have the benefits without the problems.

We could do both (and disallow multiple inheritance for the nominal subtype
relationship). But I also think it's easy to argue that this is redundant
and a bit confusing. And ultimately you *can* express most of the useful
hierarchies, even if you need a bit more boilerplate.

On Fri, Oct 20, 2023 at 8:07 AM Bakul Shah  wrote:

> On Oct 19, 2023, at 9:02 PM, Nurahmadie Nurahmadie 
> wrote:
> >
> > Is it not possible to have both _auto_ downcasting and new method
> binding to work in Go?
>
> What you are suggesting may make things more *convenient* but
> at the same time the potential for accidental mistakes goes
> up. The key is find a happy medium. Not too much discipline,
> not too much freedom!
>
>
> --
> 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/BB7C6A9

Re: [go-nuts] Can we not invoke methods on types referring to generics?

[Nurahmadie Nurahmadie]

On Fri, 20 Oct 2023 at 16:58, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> FWIW I think what OP is ultimately asking about is some form of nominal
> subtyping. When they say "automatic upcasting", they refer (I believe) to
> what Go calls "assignability", which is in essence a subtype relationship.
> So they want to be able to define a new type, that is a subtype of an
> existing type, but add some methods to it.
>

Yes, this is generally what I meant, thank you for rephrasing it more
precisely.


> And - controversially, perhaps - I don't think they would be anything
> inherently wrong about it. Except that it means we'd have two ways to have
> subtyping in the language.
>
> First, I agree with other posters here that it would be bad if `type
> String string` would create a subtype relationship between `String` and
> `string`. Ultimately, we do want to have the ability to create genuinely
> new types, with no relationship between them. It's an important safety
> mechanism.
>

This statement doesn't feel right to me, one can always do `type NewType
struct{}` to create genuinely new types, but if you do `type String
string`, for example, surely you expect String to has `string` value, hence
there will always be a relationship between them? I might be missing
something obvious here.


> But we could imagine having a new form of type declaration, say `type A <
> B` (syntax only illustrative) that would create a new type `A`, which
> inherits all methods from `B`, could add its own and which is assignable to
> `B` (but not vice-versa). We basically would have three kinds of
> declarations: 1. `type A B`, introducing no subtype relationship between
> `A` and `B`, 2. `type A < B`, which makes `A` a subtype of `B` and 3. `type
> A = B`, which makes them identical (and is conveniently equivalent to `A <
> B` and `B < A`).
>

I think it's perfectly makes sense if we resort to nominal subtyping given
the new declaration, but I'm genuinely pondering about the existing
structural subtyping characteristic instead, and I'm not trying to change
anything about Go from the discussion. :D


> I think this would honestly be fine and perfectly safe. You'd still have
> to explicitly declare that you want the new type to be a subtype, so you
> don't get the weak typing of C/C++. And the subtype relationship would only
> "flow" in one direction, so you can't *arbitrarily* mix them up.
>
> Where difficulties would arise is that it naturally leads people to want
> to subtype from *multiple* types. E.g. it would make sense wanting to do
>
> type Quadrilateral [4]Point
> func (Quadrilateral) Area() float64
> type Rhombus < Quadrilateral
> func (Rhombus) Angles() (float64, float64)
> type Rectangle < Quadrilateral
> func (Rectangle) Bounds() (min, max Point)
> type Square < (Rhombus, Rectangle) // again, syntax only illustrative)
>
> The issue this creates is that subtype relationships are transitive and in
> this case would become *path-dependent*. `Square` is a subtype of
> `Quadrilateral`, but it can get there either via `Rhombus` or via
> `Rectangle` and it's not clear which way to get there. This matters if
> `Rhombus` or `Rectangle` (or both) start overwriting methods of
> `Quadrilateral`. The compiler needs to decide which method to call. Usually
> it does that by defining some tie-breaks, e.g. "use the type named first in
> the subtype declaration". But there is a lot of implicity there and with
> deeper hierarchies, you can get spooky breakages at a distance, if some
> type in the middle of the hierarchy does some seemingly harmless change
> like overloading a method. Look up "Python Method Resolution Order" for the
> kinds of problems that can arise.
>
> Structural subtyping does not have these issues, because the subtype
> relationship is completely determined by a subset relationship - in Go's
> case, sets of methods of the dynamic type of the interface. And since it
> can't override methods, there is no path-dependence - any two methods sets
> uniquely determine a maximal common subset and a minimum common superset
> and the path from any interface type to any other interface is unique
> (structural subtyping is a Lattice
> ).
>
> I think any kind of subtyping relationship *should* ultimately allow you
> to have multiple super types - these kinds of hierarchies are just far too
> common to ignore. For example, look at the `io` package - pretty much every
> combination of `Reader`, `Writer` and `Closer` has some reasonable use
> cases. I also think there are good technical reasons to avoid the
> path-dependency pitfall. So it seems to me an easily defensible decision to
> use structural subtyping as the primary form of subtype relationship, as it
> allows you to have the benefits without the problems.
>

Structural subtyping has the most advantage in this use case, multiple
super types can be expressed with a new interface (and struct embedding as
n

Re: [go-nuts] Can we not invoke methods on types referring to generics?

['Axel Wagner' via golang-nuts]

On Fri, Oct 20, 2023 at 1:07 PM Nurahmadie Nurahmadie 
wrote:

> This statement doesn't feel right to me, one can always do `type NewType
> struct{}` to create genuinely new types, but if you do `type String
> string`, for example, surely you expect String to has `string` value, hence
> there will always be a relationship between them? I might be missing
> something obvious here.
>

I think I distinguish between a type and its representation in my mental
model. A type has a semantic meaning going beyond its representation. And
when I say "a genuinely new type" I mean - in this context - without
implying a subtype-relationship.

For example, we could imagine a world in which we had `type Path string`
and `type FilePath string`, for use with `path` and `path/filepath`,
respectively. They have the same representation (underlying type, in Go's
parlance), but they are semantically different types and they are
semantically different from a `string`. We could imagine `os.Open` to take
a `FilePath` (instead of a `string`) and for `url.URL.Path` to be a `Path`
instead of a `string`. And perhaps the `path` package could use type
parameters to manipulate such paths, like `func Join[P Path|FilePath](p
...P) P` and provide helpers to validate and convert between them, like

func ToSlash(p FilePath) Path
func FromSlash(p Path) FilePath
func Validate(s string) (Path, error)

And we'd hope that this would give us a measure of safety. We would want
the compiler to warn us if we pass a `Path` to `os.Open`, prompting us to
convert and/or validate it first. To me, we certainly would not want the
compiler to just accept us passing one as the other or vice-versa.

Now, it is true that in Go, the representation will imbue some semantic
operations on a type. e.g. the language semi-assumes that a `string` is
UTF-8 encoded text, as demonstrated by `range` and the conversion to
`[]rune`. And part of that is a lack of type-safety, where even with our
types, you could assign an arbitrary string literal to a `FilePath`, for
example. At the end of the day, Go has always been a more practically
minded, than theoretically pure language. But that doesn't disprove the
larger point, that there is an advantage to treating types as semantically
separate entities, regardless of their representation.

The way the language works right now, `type A B` really means "define a new
type A with *the same underlying type* as B". In a way, the actual *type*
`B` is inconsequential, only its representation matters. And perhaps that
was a mistake, because it conflates a type with its representation. Perhaps
we should have required the right-hand side of a type declaration to always
be a type-literal - though that would open up the question of how we deal
with `string`, `int`,… which currently are defined types on equal footing
with what you use a type-declaration for (just that they are predeclared).
Perhaps if a type-declaration would have to be clearer about the fact that
it associates a completely new type with a *representation*, this confusion
would be avoided. But it's not what happened (and TBQH I'm not sure it
would've been better).



>
>
>> But we could imagine having a new form of type declaration, say `type A <
>> B` (syntax only illustrative) that would create a new type `A`, which
>> inherits all methods from `B`, could add its own and which is assignable to
>> `B` (but not vice-versa). We basically would have three kinds of
>> declarations: 1. `type A B`, introducing no subtype relationship between
>> `A` and `B`, 2. `type A < B`, which makes `A` a subtype of `B` and 3. `type
>> A = B`, which makes them identical (and is conveniently equivalent to `A <
>> B` and `B < A`).
>>
>
> I think it's perfectly makes sense if we resort to nominal subtyping given
> the new declaration, but I'm genuinely pondering about the existing
> structural subtyping characteristic instead, and I'm not trying to change
> anything about Go from the discussion. :D
>
>
>> I think this would honestly be fine and perfectly safe. You'd still have
>> to explicitly declare that you want the new type to be a subtype, so you
>> don't get the weak typing of C/C++. And the subtype relationship would only
>> "flow" in one direction, so you can't *arbitrarily* mix them up.
>>
>> Where difficulties would arise is that it naturally leads people to want
>> to subtype from *multiple* types. E.g. it would make sense wanting to do
>>
>> type Quadrilateral [4]Point
>> func (Quadrilateral) Area() float64
>> type Rhombus < Quadrilateral
>> func (Rhombus) Angles() (float64, float64)
>> type Rectangle < Quadrilateral
>> func (Rectangle) Bounds() (min, max Point)
>> type Square < (Rhombus, Rectangle) // again, syntax only illustrative)
>>
>> The issue this creates is that subtype relationships are transitive and
>> in this case would become *path-dependent*. `Square` is a subtype of
>> `Quadrilateral`, but it can get there either via `Rhombus` or via
>> `Rectangle` and it's not clear which w

Re: [go-nuts] What tool is used in Go Playground's import handling?

[Ian Lance Taylor]

On Thu, Oct 19, 2023 at 8:31 PM Pratik Tamgole  wrote:
>
> When I use packages, any packages in general, how does the import("fmt") line 
> correct itself to include the used packages in the program? What tool is 
> implemented here, I want to put the same in my editor.

https://pkg.go.dev/golang.org/x/tools/cmd/goimports

Ian

-- 
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/CAOyqgcXh9sCOB4K9tjiDEwRrU3dprwbZHsSwkFq0H8vPQFi56Q%40mail.gmail.com.

[go-nuts] About allowing conversion from bool to int

[Victor Giordano]

Hello fellow gopherships... ¿How you doing? 

Hope just fine!

A week ago I proposed to allow conversion from bool to int, assuming false 
to 0 and true to be 1. This was the proposal 
 and I do appreciate a lot the 
polite responses from Ian.

I pick my pike and dig into... the discussion... trying to understand what 
was the force or the motivation that refuses the proposal. 

I Found two interesting comments:

   - Adg stament 
   
   - Commander statement 
   

And what i perceive is that the cons is: *It may harm readability.*

Well... If that is the case... (because, that is what I understood, and 
forget me if I'm wrong!) I have some points to put into the table if you 
allow... please, do not take it hard... I'm trying to make *an statement*. 

1) One line Swapping

a, b := 1, 2 // I never use this.. I always forget if the 1 go to the a and 
the 2 go to b or vice-versa.. (Like now!) 

I do like to write three lines instead of one...

2) Block scope, not per iteration scope 


Well...  actual web apps require to write in JavaScript, JavaScript uses  
block scopes..  so I appreciate a LOT this feature of the language, but as 
long this language has to live with other languages (like JavaScript) I 
don't feel that this will release me from the burden of knowing how to deal 
with block scopes variables used in a closure. JavaScript is not an example 
of well designed language but is the language widely used in web apps.

3) Generics... 

Well... With interfaces I already got the genericity I need to model 
abstractions.. But I do appreciate generics, because they do allow us to 
write less code at the cost complicating the language grammar. I start to 
use them... but before that I have no problem on converting an slice of 
interfaces using a for loop.

4) I "grow" writing these lines on any C program  *I'm not too old (to 
reason), but also not too young  (to dream). I have 40*

#define TRUE 1
#define FALSE 0

*That definitively has shaped my mind.*

*So the statement is*:

The points 1,2 and 3 I show... are examples of questionable (at least, for 
me) things that you directly inject into the language. The point 4 I show 
how I feel that a bool is, in turn, an int.

The proposal of making bool to int, could co exists. And people can choose 
to use it or not. You may give it a try... for me (and other folks) well 
come in handy in situations like this 

 (context: 
count the number of Spanish's cards that belongs to the GOLD suit).

If you say me: "Ey victor, we just won't put it because we don't like it" 
<- I will buy it. 

Or

You may convince me... I leave that to you. I will try to stay open (I do 
recognize myself as person that can be a little stubborn.)

Final words

Is not my language and you have done a wonderful job... I mean.. from the 
old days in C, passing thought the cosmos of C++, then OOP disembark with 
Java and C#... and then Golang mixing a lot of learned lessons into a 
single language!

Actual final words:

Informal Greetings!  🤠🧉



-- 
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/a90abe59-10da-4943-a647-8487be47529cn%40googlegroups.com.

[go-nuts] Re: About allowing conversion from bool to int

[Volker Dobler]

I use 1 a lot and 4 (or the suggested bool<-->int conv) never.
I have no idea what you want to express with 2
and 4 addresses a kind of problem that has no
simple solution like a one-line function.

V.

On Friday, 20 October 2023 at 15:12:06 UTC+2 Victor Giordano wrote:

> Hello fellow gopherships... ¿How you doing? 
>
> Hope just fine!
>
> A week ago I proposed to allow conversion from bool to int, assuming false 
> to 0 and true to be 1. This was the proposal 
>  and I do appreciate a lot the 
> polite responses from Ian.
>
> I pick my pike and dig into... the discussion... trying to understand what 
> was the force or the motivation that refuses the proposal. 
>
> I Found two interesting comments:
>
>- Adg stament 
>
>- Commander statement 
>
>
> And what i perceive is that the cons is: *It may harm readability.*
>
> Well... If that is the case... (because, that is what I understood, and 
> forget me if I'm wrong!) I have some points to put into the table if you 
> allow... please, do not take it hard... I'm trying to make *an statement*
> . 
>
> 1) One line Swapping
>
> a, b := 1, 2 // I never use this.. I always forget if the 1 go to the a 
> and the 2 go to b or vice-versa.. (Like now!) 
>
> I do like to write three lines instead of one...
>
> 2) Block scope, not per iteration scope 
> 
>
> Well...  actual web apps require to write in JavaScript, JavaScript uses  
> block scopes..  so I appreciate a LOT this feature of the language, but as 
> long this language has to live with other languages (like JavaScript) I 
> don't feel that this will release me from the burden of knowing how to deal 
> with block scopes variables used in a closure. JavaScript is not an example 
> of well designed language but is the language widely used in web apps.
>
> 3) Generics... 
>
> Well... With interfaces I already got the genericity I need to model 
> abstractions.. But I do appreciate generics, because they do allow us to 
> write less code at the cost complicating the language grammar. I start to 
> use them... but before that I have no problem on converting an slice of 
> interfaces using a for loop.
>
> 4) I "grow" writing these lines on any C program  *I'm not too old (to 
> reason), but also not too young  (to dream). I have 40*
>
> #define TRUE 1
> #define FALSE 0
>
> *That definitively has shaped my mind.*
>
> *So the statement is*:
>
> The points 1,2 and 3 I show... are examples of questionable (at least, for 
> me) things that you directly inject into the language. The point 4 I show 
> how I feel that a bool is, in turn, an int.
>
> The proposal of making bool to int, could co exists. And people can choose 
> to use it or not. You may give it a try... for me (and other folks) well 
> come in handy in situations like this 
> 
>  (context: 
> count the number of Spanish's cards that belongs to the GOLD suit).
>
> If you say me: "Ey victor, we just won't put it because we don't like it" 
> <- I will buy it. 
>
> Or
>
> You may convince me... I leave that to you. I will try to stay open (I do 
> recognize myself as person that can be a little stubborn.)
>
> Final words
>
> Is not my language and you have done a wonderful job... I mean.. from the 
> old days in C, passing thought the cosmos of C++, then OOP disembark with 
> Java and C#... and then Golang mixing a lot of learned lessons into a 
> single language!
>
> Actual final words:
>
> Informal Greetings!  🤠🧉
>
>
>
>

-- 
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/61e90e0d-30a1-4c75-b6d3-9933dcaad632n%40googlegroups.com.

Re: [go-nuts] Re: About allowing conversion from bool to int

[Victor Giordano]

Volker. I don't know how to reply to what you state. I'm open to listen or
read any thoughts you have about not using bool to int.


El vie, 20 oct 2023 a las 12:20, Volker Dobler ()
escribió:

> I use 1 a lot and 4 (or the suggested bool<-->int conv) never.
> I have no idea what you want to express with 2
> and 4 addresses a kind of problem that has no
> simple solution like a one-line function.
>
> V.
>
> On Friday, 20 October 2023 at 15:12:06 UTC+2 Victor Giordano wrote:
>
>> Hello fellow gopherships... ¿How you doing?
>>
>> Hope just fine!
>>
>> A week ago I proposed to allow conversion from bool to int, assuming
>> false to 0 and true to be 1. This was the proposal
>>  and I do appreciate a lot
>> the polite responses from Ian.
>>
>> I pick my pike and dig into... the discussion... trying to understand
>> what was the force or the motivation that refuses the proposal.
>>
>> I Found two interesting comments:
>>
>>- Adg stament
>>
>>- Commander statement
>>
>>
>> And what i perceive is that the cons is: *It may harm readability.*
>>
>> Well... If that is the case... (because, that is what I understood, and
>> forget me if I'm wrong!) I have some points to put into the table if you
>> allow... please, do not take it hard... I'm trying to make *an statement*
>> .
>>
>> 1) One line Swapping
>>
>> a, b := 1, 2 // I never use this.. I always forget if the 1 go to the a
>> and the 2 go to b or vice-versa.. (Like now!)
>>
>> I do like to write three lines instead of one...
>>
>> 2) Block scope, not per iteration scope
>> 
>>
>> Well...  actual web apps require to write in JavaScript, JavaScript uses
>> block scopes..  so I appreciate a LOT this feature of the language, but as
>> long this language has to live with other languages (like JavaScript) I
>> don't feel that this will release me from the burden of knowing how to deal
>> with block scopes variables used in a closure. JavaScript is not an example
>> of well designed language but is the language widely used in web apps.
>>
>> 3) Generics...
>>
>> Well... With interfaces I already got the genericity I need to model
>> abstractions.. But I do appreciate generics, because they do allow us to
>> write less code at the cost complicating the language grammar. I start to
>> use them... but before that I have no problem on converting an slice of
>> interfaces using a for loop.
>>
>> 4) I "grow" writing these lines on any C program  *I'm not too old (to
>> reason), but also not too young  (to dream). I have 40*
>>
>> #define TRUE 1
>> #define FALSE 0
>>
>> *That definitively has shaped my mind.*
>>
>> *So the statement is*:
>>
>> The points 1,2 and 3 I show... are examples of questionable (at least,
>> for me) things that you directly inject into the language. The point 4 I
>> show how I feel that a bool is, in turn, an int.
>>
>> The proposal of making bool to int, could co exists. And people can
>> choose to use it or not. You may give it a try... for me (and other folks)
>> well come in handy in situations like this
>> 
>>  (context:
>> count the number of Spanish's cards that belongs to the GOLD suit).
>>
>> If you say me: "Ey victor, we just won't put it because we don't like it"
>> <- I will buy it.
>>
>> Or
>>
>> You may convince me... I leave that to you. I will try to stay open (I do
>> recognize myself as person that can be a little stubborn.)
>>
>> Final words
>>
>> Is not my language and you have done a wonderful job... I mean.. from the
>> old days in C, passing thought the cosmos of C++, then OOP disembark with
>> Java and C#... and then Golang mixing a lot of learned lessons into a
>> single language!
>>
>> Actual final words:
>>
>> Informal Greetings!  🤠🧉
>>
>>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/dSvR3uskT6M/unsubscribe.
> To unsubscribe from this group and all its topics, 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/61e90e0d-30a1-4c75-b6d3-9933dcaad632n%40googlegroups.com
> 
> .
>


-- 
V

-- 
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/CAPUu

Re: [go-nuts] Re: About allowing conversion from bool to int

[Victor Giordano]

My intention is to actually know any reason about not pushing forward that
proposal... because I need to understand why... *Is there any reason out
there? I don't know where to ask *
I tried to put on the table pros and cons.. but no further feedback was
received.

*Request*
[image: image.png]

*Response*
[image: image.png]

If nobody plays along with me and shows a cost.. I will answer myself by
*timeout* this and say that there is no reason besides any personal
preference. Volker, ¿do you understand my intention? ¿it is too much to
ask?


El vie, 20 oct 2023 a las 14:48, Victor Giordano ()
escribió:

> Volker. I don't know how to reply to what you state. I'm open to listen or
> read any thoughts you have about not using bool to int.
>
>
> El vie, 20 oct 2023 a las 12:20, Volker Dobler (<
> dr.volker.dob...@gmail.com>) escribió:
>
>> I use 1 a lot and 4 (or the suggested bool<-->int conv) never.
>> I have no idea what you want to express with 2
>> and 4 addresses a kind of problem that has no
>> simple solution like a one-line function.
>>
>> V.
>>
>> On Friday, 20 October 2023 at 15:12:06 UTC+2 Victor Giordano wrote:
>>
>>> Hello fellow gopherships... ¿How you doing?
>>>
>>> Hope just fine!
>>>
>>> A week ago I proposed to allow conversion from bool to int, assuming
>>> false to 0 and true to be 1. This was the proposal
>>>  and I do appreciate a lot
>>> the polite responses from Ian.
>>>
>>> I pick my pike and dig into... the discussion... trying to understand
>>> what was the force or the motivation that refuses the proposal.
>>>
>>> I Found two interesting comments:
>>>
>>>- Adg stament
>>>
>>>- Commander statement
>>>
>>>
>>> And what i perceive is that the cons is: *It may harm readability.*
>>>
>>> Well... If that is the case... (because, that is what I understood, and
>>> forget me if I'm wrong!) I have some points to put into the table if you
>>> allow... please, do not take it hard... I'm trying to make *an
>>> statement*.
>>>
>>> 1) One line Swapping
>>>
>>> a, b := 1, 2 // I never use this.. I always forget if the 1 go to the a
>>> and the 2 go to b or vice-versa.. (Like now!)
>>>
>>> I do like to write three lines instead of one...
>>>
>>> 2) Block scope, not per iteration scope
>>> 
>>>
>>> Well...  actual web apps require to write in JavaScript, JavaScript
>>> uses  block scopes..  so I appreciate a LOT this feature of the language,
>>> but as long this language has to live with other languages (like
>>> JavaScript) I don't feel that this will release me from the burden of
>>> knowing how to deal with block scopes variables used in a closure.
>>> JavaScript is not an example of well designed language but is the language
>>> widely used in web apps.
>>>
>>> 3) Generics...
>>>
>>> Well... With interfaces I already got the genericity I need to model
>>> abstractions.. But I do appreciate generics, because they do allow us to
>>> write less code at the cost complicating the language grammar. I start to
>>> use them... but before that I have no problem on converting an slice of
>>> interfaces using a for loop.
>>>
>>> 4) I "grow" writing these lines on any C program  *I'm not too old (to
>>> reason), but also not too young  (to dream). I have 40*
>>>
>>> #define TRUE 1
>>> #define FALSE 0
>>>
>>> *That definitively has shaped my mind.*
>>>
>>> *So the statement is*:
>>>
>>> The points 1,2 and 3 I show... are examples of questionable (at least,
>>> for me) things that you directly inject into the language. The point 4 I
>>> show how I feel that a bool is, in turn, an int.
>>>
>>> The proposal of making bool to int, could co exists. And people can
>>> choose to use it or not. You may give it a try... for me (and other folks)
>>> well come in handy in situations like this
>>> 
>>>  (context:
>>> count the number of Spanish's cards that belongs to the GOLD suit).
>>>
>>> If you say me: "Ey victor, we just won't put it because we don't like
>>> it" <- I will buy it.
>>>
>>> Or
>>>
>>> You may convince me... I leave that to you. I will try to stay open (I
>>> do recognize myself as person that can be a little stubborn.)
>>>
>>> Final words
>>>
>>> Is not my language and you have done a wonderful job... I mean.. from
>>> the old days in C, passing thought the cosmos of C++, then OOP disembark
>>> with Java and C#... and then Golang mixing a lot of learned lessons into a
>>> single language!
>>>
>>> Actual final words:
>>>
>>> Informal Greetings!  🤠🧉
>>>
>>>
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nut

Re: [go-nuts] Re: About allowing conversion from bool to int

[Volker Dobler]

I have to admit I do not understand your intention.
You made a proposal to change the language.
A lot of people (me included) do not see this change
as good (not needed, other solutions are available,
lots of drawbacks, bad experience with such stuff
in general, edge case, can be done in trivial code,
etc. pp.) You seem to not like these arguments and 
think your pro arguments are better?

I'm sorry but I cannot contribute anything with
more "substance" here.

V. 

On Friday, 20 October 2023 at 23:15:07 UTC+2 Victor Giordano wrote:

>
> My intention is to actually know any reason about not pushing forward that 
> proposal... because I need to understand why... *Is there any reason out 
> there? I don't know where to ask *
> I tried to put on the table pros and cons.. but no further feedback was 
> received. 
>
> *Request*
> [image: image.png]
>
> *Response*
> [image: image.png]
>
> If nobody plays along with me and shows a cost.. I will answer myself by 
> *timeout* this and say that there is no reason besides any personal 
> preference. Volker, ¿do you understand my intention? ¿it is too much to 
> ask? 
>
>
> El vie, 20 oct 2023 a las 14:48, Victor Giordano () 
> escribió:
>
>> Volker. I don't know how to reply to what you state. I'm open to listen 
>> or read any thoughts you have about not using bool to int.
>>
>>
>> El vie, 20 oct 2023 a las 12:20, Volker Dobler () 
>> escribió:
>>
>>> I use 1 a lot and 4 (or the suggested bool<-->int conv) never.
>>> I have no idea what you want to express with 2
>>> and 4 addresses a kind of problem that has no
>>> simple solution like a one-line function.
>>>
>>> V.
>>>
>>> On Friday, 20 October 2023 at 15:12:06 UTC+2 Victor Giordano wrote:
>>>
 Hello fellow gopherships... ¿How you doing? 

 Hope just fine!

 A week ago I proposed to allow conversion from bool to int, assuming 
 false to 0 and true to be 1. This was the proposal 
  and I do appreciate a lot 
 the polite responses from Ian.

 I pick my pike and dig into... the discussion... trying to understand 
 what was the force or the motivation that refuses the proposal. 

 I Found two interesting comments:

- Adg stament 

- Commander statement 


 And what i perceive is that the cons is: *It may harm readability.*

 Well... If that is the case... (because, that is what I understood, and 
 forget me if I'm wrong!) I have some points to put into the table if you 
 allow... please, do not take it hard... I'm trying to make *an 
 statement*. 

 1) One line Swapping

 a, b := 1, 2 // I never use this.. I always forget if the 1 go to the a 
 and the 2 go to b or vice-versa.. (Like now!) 

 I do like to write three lines instead of one...

 2) Block scope, not per iteration scope 
 

 Well...  actual web apps require to write in JavaScript, JavaScript 
 uses  block scopes..  so I appreciate a LOT this feature of the language, 
 but as long this language has to live with other languages (like 
 JavaScript) I don't feel that this will release me from the burden of 
 knowing how to deal with block scopes variables used in a closure. 
 JavaScript is not an example of well designed language but is the language 
 widely used in web apps.

 3) Generics... 

 Well... With interfaces I already got the genericity I need to model 
 abstractions.. But I do appreciate generics, because they do allow us to 
 write less code at the cost complicating the language grammar. I start to 
 use them... but before that I have no problem on converting an slice of 
 interfaces using a for loop.

 4) I "grow" writing these lines on any C program  *I'm not too old (to 
 reason), but also not too young  (to dream). I have 40*

 #define TRUE 1
 #define FALSE 0

 *That definitively has shaped my mind.*

 *So the statement is*:

 The points 1,2 and 3 I show... are examples of questionable (at least, 
 for me) things that you directly inject into the language. The point 4 I 
 show how I feel that a bool is, in turn, an int.

 The proposal of making bool to int, could co exists. And people can 
 choose to use it or not. You may give it a try... for me (and other folks) 
 well come in handy in situations like this 
 
  (context: 
 count the number of Spanish's cards that belongs to the GOLD suit).

 If you say me: "Ey victor, we just won't put it because we don't like 
 it" <- I will buy it. 

 Or

 Yo

Fwd: [go-nuts] Re: About allowing conversion from bool to int

[Victor Giordano]

-- Forwarded message -
De: Victor Giordano 
Date: vie, 20 oct 2023 a las 19:09
Subject: Re: [go-nuts] Re: About allowing conversion from bool to int
To: Volker Dobler 


Volker I'm very grateful for your answer! Thanks!!!

> A lot of people (me included) do not see this change
as good (not needed, other solutions are available,
lots of drawbacks, bad experience with such stuff
in general, edge case, can be done in trivial code,
etc. pp.)
All these reasons are valid but I'm a little afraid of arguing right now.
You don't seem to be open to critics or other visions. Also I know and I
understand that you don't have to. In any case, thanks for the insight.

> You seem to not like these arguments
That totally right

> and  think your pro arguments are better?
I do not say that (you may point me where I do say that...) neither was my
intention.

My intention is to discover any reason that can convince me. Also I'm in
the mood for discussing, this is a group for discussion, right?

Thanks again.


El vie, 20 oct 2023 a las 18:47, Volker Dobler ()
escribió:

> I have to admit I do not understand your intention.
> You made a proposal to change the language.
> A lot of people (me included) do not see this change
> as good (not needed, other solutions are available,
> lots of drawbacks, bad experience with such stuff
> in general, edge case, can be done in trivial code,
> etc. pp.) You seem to not like these arguments and
> think your pro arguments are better?
>
> I'm sorry but I cannot contribute anything with
> more "substance" here.
>
> V.
>
> On Friday, 20 October 2023 at 23:15:07 UTC+2 Victor Giordano wrote:
>
>>
>> My intention is to actually know any reason about not pushing
>> forward that proposal... because I need to understand why... *Is there
>> any reason out there? I don't know where to ask *
>> I tried to put on the table pros and cons.. but no further feedback was
>> received.
>>
>> *Request*
>> [image: image.png]
>>
>> *Response*
>> [image: image.png]
>>
>> If nobody plays along with me and shows a cost.. I will answer myself by
>> *timeout* this and say that there is no reason besides any personal
>> preference. Volker, ¿do you understand my intention? ¿it is too much to
>> ask?
>>
>>
>> El vie, 20 oct 2023 a las 14:48, Victor Giordano ()
>> escribió:
>>
>>> Volker. I don't know how to reply to what you state. I'm open to listen
>>> or read any thoughts you have about not using bool to int.
>>>
>>>
>>> El vie, 20 oct 2023 a las 12:20, Volker Dobler ()
>>> escribió:
>>>
 I use 1 a lot and 4 (or the suggested bool<-->int conv) never.
 I have no idea what you want to express with 2
 and 4 addresses a kind of problem that has no
 simple solution like a one-line function.

 V.

 On Friday, 20 October 2023 at 15:12:06 UTC+2 Victor Giordano wrote:

> Hello fellow gopherships... ¿How you doing?
>
> Hope just fine!
>
> A week ago I proposed to allow conversion from bool to int, assuming
> false to 0 and true to be 1. This was the proposal
>  and I do appreciate a lot
> the polite responses from Ian.
>
> I pick my pike and dig into... the discussion... trying to understand
> what was the force or the motivation that refuses the proposal.
>
> I Found two interesting comments:
>
>- Adg stament
>
>- Commander statement
>
>
> And what i perceive is that the cons is: *It may harm readability.*
>
> Well... If that is the case... (because, that is what I understood,
> and forget me if I'm wrong!) I have some points to put into the table if
> you allow... please, do not take it hard... I'm trying to make *an
> statement*.
>
> 1) One line Swapping
>
> a, b := 1, 2 // I never use this.. I always forget if the 1 go to the
> a and the 2 go to b or vice-versa.. (Like now!)
>
> I do like to write three lines instead of one...
>
> 2) Block scope, not per iteration scope
> 
>
> Well...  actual web apps require to write in JavaScript, JavaScript
> uses  block scopes..  so I appreciate a LOT this feature of the language,
> but as long this language has to live with other languages (like
> JavaScript) I don't feel that this will release me from the burden of
> knowing how to deal with block scopes variables used in a closure.
> JavaScript is not an example of well designed language but is the language
> widely used in web apps.
>
> 3) Generics...
>
> Well... With interfaces I already got the genericity I need to model
> abstractions.. But I do appreciate generics, because they do allow us to
> write less code at the cost complicating the language grammar

Re: [go-nuts] Re: About allowing conversion from bool to int

[Ian Lance Taylor]

On Fri, Oct 20, 2023 at 2:14 PM Victor Giordano 
wrote:

>
> My intention is to actually know any reason about not pushing forward that
> proposal... because I need to understand why... *Is there any reason out
> there? I don't know where to ask *
>

The first step is to read https://go.dev/issue/9367 and
https://go.dev/issue/45320.  There are various reasons in those issues.

It's may be useful to distinguish _any reason_ from _a reason you agree
with_.  Even if you don't agree with the reasons in those issues, they are
still reasons, and other people find them convincing.

Ian

-- 
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/CAOyqgcXvu61ZzNt5d7RcUNTGM7NeoSkWOaNcWDygT0vArYrgKA%40mail.gmail.com.

Re: [go-nuts] Re: About allowing conversion from bool to int

[Victor Giordano]

Ian thanks!

Yes.. I admit  that I haven't read those issues entirely Now I have
finished reading and also reach this very interesting issue


At first glance I noticed these comments

   - Adg commentt
   
   - Robe email response
   

Then (On the second read...)

   - Ian comment
   
 and Magical
   comment
   
   - Shawmilo comment
   
   - Minux comment
   


Ok...that's enough... don't convince me completely but it may be the right
thing 🤔... yes... you all have fair points
And allow me to say that when discussing with a buddy at work he states
"ey, a reason could be to keep minimalism... so you get less ways to do the
same, it is more straightforward.. less choices, less doubts" that
statement shakes me.. almost convinced me.  But again... I see we don't
think quite the same nevertheless my thirst for understanding more was
fulfilled..

According to the reactions on this issue's initial comment... it seems that
there are more people in favor than against..  Perhaps there will be any
slight change to consider or cast a votation sometime in the future..?

Thanks for your patience!..
Greetings



El vie, 20 oct 2023 a las 21:31, Ian Lance Taylor ()
escribió:

> On Fri, Oct 20, 2023 at 2:14 PM Victor Giordano 
> wrote:
>
>>
>> My intention is to actually know any reason about not pushing
>> forward that proposal... because I need to understand why... *Is there
>> any reason out there? I don't know where to ask *
>>
>
> The first step is to read https://go.dev/issue/9367 and
> https://go.dev/issue/45320.  There are various reasons in those issues.
>
> It's may be useful to distinguish _any reason_ from _a reason you agree
> with_.  Even if you don't agree with the reasons in those issues, they are
> still reasons, and other people find them convincing.
>


>
> Ian
>


-- 
V

-- 
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/CAPUu9svvm05rQ4yADvYyZh7prfU1_qo%3DtUNhn%3D7NwDzvaHCDVA%40mail.gmail.com.