Re: [go-nuts] Re: [rfc] build bug in type abstraction?

[John Pritchard]

Hi Brian,

Thanks for the review.  Your basic conclusion matches mine, that the
./main/main.go:46 and ./types.go are proven in the "go run" case, and
disproven in the "go build" case.

Best,

John


On Wed, Aug 16, 2023 at 9:58 AM Brian Candler  wrote:

> On Wednesday, 16 August 2023 at 14:05:49 UTC+1 John Pritchard wrote:
>
> I have a disparity between "go run" [
> https://go.dev/play/p/5mr5M0luZ9k?v=goprev]
> and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].
> Using go version 1.21.0.
>
>
> I don't quite understand where "go run" comes into this.  In your Makefile
> ,
> both options use "go build".
>
> "make list" is doing something dubious:
>
> go_sources := $(shell ls *.go)
> ...
> list: main/main.go $(go_sources)
> go build -o $@ $<
>
> That is, I think you're trying to compile "main/main.go" and "types.go" at
> the same time into a single object file.  But types.go is "package types"
> whereas main.go is "package main".  That should give you an error; if it
> doesn't, that makes me suspect that go_sources is in fact empty.  The "make
> list" output you show in README.txt appears to confirm this:
>
> $ make
> go build -o list main/main.go# <<< note that no additional sources are
> listed on the command line
>
> In main.go, there is a pretty clear error that the compiler calls out in
> line 46:
> main/main.go:46:15: undefined: Abstract
>
> The corresponding source line
> 
> is:
> var abstract Abstract = types.Init()
>
> and as far as I can see, it's correct: you have no type "Abstract" in
> package main in main.go (in otherwise, you should be referring to
> "types.Abstract")
>
>
> --
> 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/a0716bee-a6b9-4ea7-b4a7-165c4ef43fabn%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/CAD6mcO85tazOOrykPzp0XEg7FRfT7vKDLSk-fevrFm7sxMGaCQ%40mail.gmail.com.

Re: [go-nuts] Ambiguous Method Promotion Bug?

['Axel Wagner' via golang-nuts]

"and so does zz.X.Fun", of course.

On Tue, Nov 17, 2020 at 10:14 PM Axel Wagner 
wrote:

> Hi,
>
> the relevant spec section is https://golang.org/ref/spec#Selectors
>
> A selector f may denote a field or method f of a type T, or it may refer
>> to a field or method f of a nested embedded field of T. The number of
>> embedded fields traversed to reach f is called its depth in T. The depth of
>> a field or method f declared in T is zero. The depth of a field or method f
>> declared in an embedded field A in T is the depth of f in A plus one.
>
>
> and
>
> For a value x of type T or *T where T is not a pointer or interface type,
>> x.f denotes the field or method at the shallowest depth in T where there is
>> such an f. If there is not exactly one f with shallowest depth, the
>> selector expression is illegal.
>
>
> In your example, zz.Fun refers to zz.Y.Fun, as that has a depth of 1,
> whereas zz.Q.Fun has a depth of 2 (Q has depth 1 and Fun has depth 1 within
> Q) and zz.X.Fun (X has depth 2 in Z and Fun has depth 0 in X).
>
> Note, in particular, that the check happens at the selector expression,
> not at the type-definition. This is intentional, as it means you can embed
> multiple types without it being an error if they have the same
> fields/methods.
>
> I agree that all of this makes not necessarily for the most readable code,
> but the rule that the shallowest depth must be unique is what makes the
> selector well-defined.
>
> On Tue, Nov 17, 2020 at 9:57 PM Michal Ostrowski 
> wrote:
>
>>
>> Here is a playground doc that demonstrates what seems to be strange
>> behavior regarding promotion of methods.
>>
>> https://play.golang.org/p/R9M1lAOd9CA
>>
>> It seems that I can generate a struct a have an ambiguous method by
>> adding a level of indirection in struct definitions.  Or there's something
>> in the language spec that I'm missing (and I'd appreciate a reference to
>> that in that case.)
>>
>>
>>
>> --
>> 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/cb606644-1b76-4db1-af8c-96b5efac1c20n%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/CAEkBMfFQkMhqdVZL8ydN69uV85uRhRE%2Bs%3DKJ6ECMNSwLoqhgUQ%40mail.gmail.com.

Re: [go-nuts] Ambiguous Method Promotion Bug?

['Axel Wagner' via golang-nuts]

Hi,

the relevant spec section is https://golang.org/ref/spec#Selectors

A selector f may denote a field or method f of a type T, or it may refer to
> a field or method f of a nested embedded field of T. The number of embedded
> fields traversed to reach f is called its depth in T. The depth of a field
> or method f declared in T is zero. The depth of a field or method f
> declared in an embedded field A in T is the depth of f in A plus one.


and

For a value x of type T or *T where T is not a pointer or interface type,
> x.f denotes the field or method at the shallowest depth in T where there is
> such an f. If there is not exactly one f with shallowest depth, the
> selector expression is illegal.


In your example, zz.Fun refers to zz.Y.Fun, as that has a depth of 1,
whereas zz.Q.Fun has a depth of 2 (Q has depth 1 and Fun has depth 1 within
Q) and zz.X.Fun (X has depth 2 in Z and Fun has depth 0 in X).

Note, in particular, that the check happens at the selector expression, not
at the type-definition. This is intentional, as it means you can embed
multiple types without it being an error if they have the same
fields/methods.

I agree that all of this makes not necessarily for the most readable code,
but the rule that the shallowest depth must be unique is what makes the
selector well-defined.

On Tue, Nov 17, 2020 at 9:57 PM Michal Ostrowski  wrote:

>
> Here is a playground doc that demonstrates what seems to be strange
> behavior regarding promotion of methods.
>
> https://play.golang.org/p/R9M1lAOd9CA
>
> It seems that I can generate a struct a have an ambiguous method by adding
> a level of indirection in struct definitions.  Or there's something in the
> language spec that I'm missing (and I'd appreciate a reference to that in
> that case.)
>
>
>
> --
> 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/cb606644-1b76-4db1-af8c-96b5efac1c20n%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/CAEkBMfEkpAKtQo0zUrZ5hwEUa9wEYy%2BX4M_j17mniuap6R-uWw%40mail.gmail.com.

Re: [go-nuts] Is this a bug?

[roger peppe]

There's a Go issue which is relevant here:
https://github.com/golang/go/issues/8082


On Sat, 25 May 2019 at 04:54, Dan Kortschak  wrote:

> The interfaces that define the contracts should come from a third
> package/source. The issue that I suspect you are hitting is that type
> identity for interface types is based on the name, not the method set.
> This means that, for example with your code below a function
> PrintB(StringerB) and another function PrintA(StringerA) are not
> assignable to the same variable unless it is type interface{}.
>
> https://play.golang.org/p/a8aWwA6CAB_K // remove comment to see failure
>
> On Fri, 2019-05-24 at 20:38 -0700, Henry wrote:
> > Thanks for the reply.
> >
> > Is there any specific use case that this intended behavior is
> > supposed to
> > solve? It appears to me that it is just a case of simplistic
> > implementation
> > where Go does not look deep enough to see if any dependent interfaces
> > are
> > identical. In this case, Go does not bother to look beyond Formatter
> > interface in order to conclude whether FormatterA and FormatterB are
> > identical. In here, I define 'identical' as being interchangeable,
> > rather
> > than semantic equality. So when I refer to TypeA and TypeB as
> > identical, it
> > means you can use TypeA in place of TypeB, and vice versa.
> >
> > Back to the actual situation, Package A and Package B are developed
> > in
> > tandem by different teams. They have some communication on how their
> > components will interact with each other and fit the bigger picture.
> > They
> > use interface to define contracts that are required in order for
> > their
> > components to work. Since Go interface is implicit, this is supposed
> > to
> > work fine. As an example, if I were to reduce the prior example as
> > follows,
> > it works fine. (Link to the playground:
> > https://play.golang.org/p/zrpjSYTIyxZ)
> >
> > import (
> > "fmt"
> > )
> >
> > func main() {
> > str := MyString("Hello world!")
> > Print(str)
> >
> > strA:=StringerA(str)
> > Print(strA)
> > }
> >
> > type StringerA interface {
> > String() string
> > }
> >
> > type StringerB interface {
> > String() string
> > }
> >
> > type MyString string
> >
> > func (s MyString) String() string {
> > return string(s)
> > }
> >
> > func Print(s StringerB) {
> > fmt.Println(s.String())
> > }
> >
> > However, when I add a more complex interface, as in the first
> > example
> > involving Formatter, it breaks. Go fails to recognize that FormatterA
> > and
> > FormatterB are interchangeable despite the facts that their
> > dependencies
> > (StringerA and StringerB) are interchangeable. Visually, the
> > components
> > should look like this:
> >
> > [image: go.png]
> > Let me know what you think.
> >
> > Thanks.
> >
> > Henry
> >
> > On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
> > >
> > > It's not a bug, FormatterA and FormatterB method has different
> > > signatures, they are not identical, one wants Format(StringerA)
> > > other
> > > Format(StringerB), thus your Format type only implements
> > > FormatterA
> > > but Print wants a FormatterB.
> > >
> >
> >
>
> --
> 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/71965bccd27ed0288b09f9b5b1b3dfc75b3a4ef2.camel%40kortschak.io
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJhgachMAM1X9yKF5tNoSaNxOnEmWPnGr4Akiq6jp_j%3DZoO4HA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Dan Kortschak]

The interfaces that define the contracts should come from a third
package/source. The issue that I suspect you are hitting is that type
identity for interface types is based on the name, not the method set.
This means that, for example with your code below a function
PrintB(StringerB) and another function PrintA(StringerA) are not
assignable to the same variable unless it is type interface{}.

https://play.golang.org/p/a8aWwA6CAB_K // remove comment to see failure

On Fri, 2019-05-24 at 20:38 -0700, Henry wrote:
> Thanks for the reply. 
> 
> Is there any specific use case that this intended behavior is
> supposed to 
> solve? It appears to me that it is just a case of simplistic
> implementation 
> where Go does not look deep enough to see if any dependent interfaces
> are 
> identical. In this case, Go does not bother to look beyond Formatter 
> interface in order to conclude whether FormatterA and FormatterB are 
> identical. In here, I define 'identical' as being interchangeable,
> rather 
> than semantic equality. So when I refer to TypeA and TypeB as
> identical, it 
> means you can use TypeA in place of TypeB, and vice versa. 
> 
> Back to the actual situation, Package A and Package B are developed
> in 
> tandem by different teams. They have some communication on how their 
> components will interact with each other and fit the bigger picture.
> They 
> use interface to define contracts that are required in order for
> their 
> components to work. Since Go interface is implicit, this is supposed
> to 
> work fine. As an example, if I were to reduce the prior example as
> follows, 
> it works fine. (Link to the playground: 
> https://play.golang.org/p/zrpjSYTIyxZ)
> 
> import (
> "fmt"
> )
> 
> func main() {
> str := MyString("Hello world!")
> Print(str)
> 
> strA:=StringerA(str)
> Print(strA)
> }
> 
> type StringerA interface {
> String() string
> }
> 
> type StringerB interface {
> String() string
> }
> 
> type MyString string
> 
> func (s MyString) String() string {
> return string(s)
> }
> 
> func Print(s StringerB) {
> fmt.Println(s.String())
> }
> 
> However, when I add a more complex interface, as in the first
> example 
> involving Formatter, it breaks. Go fails to recognize that FormatterA
> and 
> FormatterB are interchangeable despite the facts that their
> dependencies 
> (StringerA and StringerB) are interchangeable. Visually, the
> components 
> should look like this:
> 
> [image: go.png]
> Let me know what you think.
> 
> Thanks.
> 
> Henry
> 
> On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
> > 
> > It's not a bug, FormatterA and FormatterB method has different 
> > signatures, they are not identical, one wants Format(StringerA)
> > other 
> > Format(StringerB), thus your Format type only implements
> > FormatterA 
> > but Print wants a FormatterB. 
> > 
> 
> 

-- 
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/71965bccd27ed0288b09f9b5b1b3dfc75b3a4ef2.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Henry]

The posted diagram isn't correct. Updated the diagram with the new one.

[image: go1.png]


On Saturday, May 25, 2019 at 10:38:42 AM UTC+7, Henry wrote:
>
> Thanks for the reply. 
>
> Is there any specific use case that this intended behavior is supposed to 
> solve? It appears to me that it is just a case of simplistic implementation 
> where Go does not look deep enough to see if any dependent interfaces are 
> identical. In this case, Go does not bother to look beyond Formatter 
> interface in order to conclude whether FormatterA and FormatterB are 
> identical. In here, I define 'identical' as being interchangeable, rather 
> than semantic equality. So when I refer to TypeA and TypeB as identical, it 
> means you can use TypeA in place of TypeB, and vice versa. 
>
> Back to the actual situation, Package A and Package B are developed in 
> tandem by different teams. They have some communication on how their 
> components will interact with each other and fit the bigger picture. They 
> use interface to define contracts that are required in order for their 
> components to work. Since Go interface is implicit, this is supposed to 
> work fine. As an example, if I were to reduce the prior example as follows, 
> it works fine. (Link to the playground: 
> https://play.golang.org/p/zrpjSYTIyxZ)
>
> import (
> "fmt"
> )
>
> func main() {
> str := MyString("Hello world!")
> Print(str)
> 
> strA:=StringerA(str)
> Print(strA)
> }
>
> type StringerA interface {
> String() string
> }
>
> type StringerB interface {
> String() string
> }
>
> type MyString string
>
> func (s MyString) String() string {
> return string(s)
> }
>
> func Print(s StringerB) {
> fmt.Println(s.String())
> }
>
> However, when I add a more complex interface, as in the first example 
> involving Formatter, it breaks. Go fails to recognize that FormatterA and 
> FormatterB are interchangeable despite the facts that their dependencies 
> (StringerA and StringerB) are interchangeable. Visually, the components 
> should look like this:
>
> [image: go.png]
> Let me know what you think.
>
> Thanks.
>
> Henry
>
> On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
>>
>> It's not a bug, FormatterA and FormatterB method has different 
>> signatures, they are not identical, one wants Format(StringerA) other 
>> Format(StringerB), thus your Format type only implements FormatterA 
>> but Print wants a FormatterB. 
>>
>

-- 
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/86e27716-0dbc-42bd-9c81-45243988c3b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Burak Serdar]

On Fri, May 24, 2019 at 10:55 AM Henry  wrote:
>
> Hi,
>
> I stumbled across this weird behavior and I wonder whether this is a bug. 
> Here is the simplified version of the problem (Playground link 
> https://play.golang.org/p/mch6NQdTpr5):

I believe this is working as intended because a type implements an
interface if it has the same method signatures as that interface, and
Format(StringerA) is different from Format(StringerB). However, I
wonder if there is any real reason why this is so because it appears
that the type comparison can be "isCompatible" instead of
"isIdentical" for the argument and return types, and things would
still work.

>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
> str := MyString("World")
> var formatter Format
> Print(formatter, str) //ERROR: have Format(StringerA) string, want 
> Format(StringerB) string
> }
>
> //StringerA and StringerB are identical. Some may wonder why declare 
> identical interfaces in the same package.
> //In a real world example, they live in different packages. StringerA resides 
> in Package A and StringerB is in Package B.
>
> type StringerA interface {
> String() string
> }
>
> type StringerB interface {
> String() string
> }
>
>
> //MyString is the concrete implementation of Stringer. It applies to both 
> StringerA and StringerB.
>
> type MyString string
>
> func (m MyString) String() string {
> return string(m)
> }
>
>
> //Then, we have the Formatter. FormatterA and FormatterB are supposed to be 
> identical. They both accept a Stringer.
> //FormatterA accepts StringerA, because they are in the same package. 
> FormatterB accepts StringerB. Package A and Package B
> //are probably authored by different people and they define their own 
> Stringer. However, since we are dealing with interfaces,
> //so behaviour-wise, they are supposed to be identical. They format a 
> Stringer.
>
> type FormatterA interface {
> Format(StringerA) string
> }
>
> type FormatterB interface {
> Format(StringerB) string
> }
>
>
> //Format is the concrete implementation of Formatter. In this case, Format is 
> implemented by the author of Package A. Let's call him Author A.
> //Hence, we see StringerA there because StringerA is Author A definition of 
> Stringer. However, it is intended to work on any Stringer.
>
> type Format struct{}
>
> func (f Format) Format(s StringerA) string {
> return fmt.Sprintf("Hello %s!", s)
> }
>
>
> //Print is written by Author B. She uses FormatterB and StringerB. Those 
> interfaces are the 'contracts' she requires for her function to work.
> //Her intention is for Print to work with any Formatter and any Stringer. 
> However, Go apparently treat FormatterA and FormatterB as being different.
> //Is this a bug?
>
> func Print(f FormatterB, s StringerB) {
> fmt.Println(f.Format(s))
> }
>
>
> Thanks
>
>
> Henry
>
> --
> 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/e5eb2946-e865-40cd-b1f7-3d445d423e00%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAMV2RqoW5xBT1vKDdNGWLMitXaMkFUypoNGhcVu0EyLVC4Q6_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Wagner Riffel]

It's not a bug, FormatterA and FormatterB method has different
signatures, they are not identical, one wants Format(StringerA) other
Format(StringerB), thus your Format type only implements FormatterA
but Print wants a FormatterB.

-- 
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/CAFEfeLx%3DLWw5oioneg%3DSFDABJTuM0z4F7fHygh5WFsxHkWgf5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] golang.org/x/oauth2 bug???

[Burak Serdar]

On Fri, Dec 7, 2018 at 6:46 AM Harald Fuchs  wrote:
>
> I think there's something fishy about clientcredentials.  Having
> trouble with client_secrets containig special chars, first I modified
> clientcredentials_test.go like this:
>
> > func TestTokenRequest(t *testing.T) {
> > cfg := newConf("")
> > data := fmt.Sprintf("%s:%s", cfg.ClientID, cfg.ClientSecret)
> > sEnc := base64.StdEncoding.EncodeToString([]byte(data))
> > ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r 
> > *http.Request) {
> > if r.URL.String() != "/token" {
> > t.Errorf("authenticate client request URL = %q; want %q", r.URL, "/token")
> > }
> > headerAuth := r.Header.Get("Authorization")
> > if headerAuth != "Basic "+sEnc {
> > ...
>
> "go test ." succeeded, obviously.
>
> Then I modified the client_secret:
>
> > ClientSecret:   "CLIENT_SECRET=",
>
> Now "go test ." failed!
>
> Changing internal/token.go like this:
>
> > if !bustedAuth {
> > //req.SetBasicAuth(url.QueryEscape(clientID), url.QueryEscape(clientSecret))
> > req.SetBasicAuth(clientID, clientSecret)
> > }

IIRC, Oauth spec requires clientId and clientSecret passed as query
params. There is some code in go oauth implementation to work around
some servers that require clientId/clientSecret in different places,
like Auth header. You are passing the clientId/clientSecret in auth
header, but your servers implementation is not one of the "busted"
ones, so it is expecting to see them in the query, and escaping them
correctly. So you should either send those to in the query, or somehow
convince the library that your test is one of the busted servers.

>
> made "go test ." succeed again.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

[T L]

On Saturday, March 17, 2018 at 1:54:17 AM UTC-4, T L wrote:
>
>
>
> On Friday, March 16, 2018 at 3:31:23 PM UTC-4, Axel Wagner wrote:
>>
>>
>>
>> On Fri, Mar 16, 2018 at 8:20 PM, T L  wrote:
>>
>>>
>>>
>>> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:

 On Fri, Mar 16, 2018 at 7:40 PM T L  wrote:


 > I feel the second append call should be also valid.

 Works as intended: T is not struct{}

 If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw


 -- 

 -j

>>>
>>> yes, alias works.
>>>
>>> Just realize that this is not a "append" specified question.
>>> I feel the following one should be also valid.
>>>
>>
>> This is the same question of why you can't convert `[]int` to 
>> `[]interface{}` - it's a costly operation and Go tends to not hide 
>> expensive operations from you.
>>
>
> Yes. But I think there is a little specialty here.
> It is a problem of which viewpoint is right.
> 1. fmt.Println(1, 2, 3) is a shorthand of fmt.Println([]interface{1, 2, 
> 3}...)
> 2. fmt.Println(aBlankInterfaceSlice...) is a shorthand of 
> fmt.Println(aBlankInterfaceSlice[0], aBlankInterfaceSlice[1], ..., 
> aBlankInterfaceSlice[N])
>

Go spec does imply the first viewpoint is right.
 

>  
>
>>  
>>
>>>
>>> package main
>>>
>>> import "fmt"
>>>
>>> func main() {
>>> s := []int{1, 2, 3}
>>> fmt.Println(s...)
>>> }
>>>
>>>  
>>>
>>> -- 
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

[T L]

On Friday, March 16, 2018 at 3:31:23 PM UTC-4, Axel Wagner wrote:
>
>
>
> On Fri, Mar 16, 2018 at 8:20 PM, T L  
> wrote:
>
>>
>>
>> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:
>>>
>>> On Fri, Mar 16, 2018 at 7:40 PM T L  wrote:
>>>
>>>
>>> > I feel the second append call should be also valid.
>>>
>>> Works as intended: T is not struct{}
>>>
>>> If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw
>>>
>>>
>>> -- 
>>>
>>> -j
>>>
>>
>> yes, alias works.
>>
>> Just realize that this is not a "append" specified question.
>> I feel the following one should be also valid.
>>
>
> This is the same question of why you can't convert `[]int` to 
> `[]interface{}` - it's a costly operation and Go tends to not hide 
> expensive operations from you.
>

Yes. But I think there is a little specialty here.
It is a problem of which viewpoint is right.
1. fmt.Println(1, 2, 3) is a shorthand of fmt.Println([]interface{1, 2, 
3}...)
2. fmt.Println(aBlankInterfaceSlice...) is a shorthand of 
fmt.Println(aBlankInterfaceSlice[0], aBlankInterfaceSlice[1], ..., 
aBlankInterfaceSlice[N])
 

>  
>
>>
>> package main
>>
>> import "fmt"
>>
>> func main() {
>> s := []int{1, 2, 3}
>> fmt.Println(s...)
>> }
>>
>>  
>>
>> -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

['Axel Wagner' via golang-nuts]

On Fri, Mar 16, 2018 at 8:20 PM, T L  wrote:

>
>
> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:
>>
>> On Fri, Mar 16, 2018 at 7:40 PM T L  wrote:
>>
>>
>> > I feel the second append call should be also valid.
>>
>> Works as intended: T is not struct{}
>>
>> If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw
>>
>>
>> --
>>
>> -j
>>
>
> yes, alias works.
>
> Just realize that this is not a "append" specified question.
> I feel the following one should be also valid.
>

This is the same question of why you can't convert `[]int` to
`[]interface{}` - it's a costly operation and Go tends to not hide
expensive operations from you.


>
> package main
>
> import "fmt"
>
> func main() {
> s := []int{1, 2, 3}
> fmt.Println(s...)
> }
>
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

[T L]

On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:
>
> On Fri, Mar 16, 2018 at 7:40 PM T L  
> wrote:
>
>
> > I feel the second append call should be also valid.
>
> Works as intended: T is not struct{}
>
> If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw
>
>
> -- 
>
> -j
>

yes, alias works.

Just realize that this is not a "append" specified question.
I feel the following one should be also valid.

package main

import "fmt"

func main() {
s := []int{1, 2, 3}
fmt.Println(s...)
}

 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

[Jan Mercl]

On Fri, Mar 16, 2018 at 7:40 PM T L  wrote:


> I feel the second append call should be also valid.

Works as intended: T is not struct{}

If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw


-- 

-j

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Marvin Renich]

The point to remember is that each value of a concrete type has exactly
that one concrete type, while each value of an interface type has
exactly one interface type and one concrete type.

It is also important to note that there is a distinction between
"assignability" and "type-assertiblity".

* Bakul Shah  [180225 03:48]:
> https://play.golang.org/p/IMWd3cvgfsU
> 
> // also replicated below
> 
> package main
> 
> import (
>   "fmt"
> )
> 
> type (
>   T1 interface{ f1()int; f2()int }
>   T2 interface{ f2()int; f3()int }
> )
> type C int
> func (c C)f1()int {return 1}
> func (c C)f2()int {return 2}
> func (c C)f3()int {return 3}
> 
> func main() {
>   var (x1 T1; x2 T2; c C; o interface{})
>   fmt.Printf("%T, %T, %T, %T\n", x1, x2, o, c)
>   p(x1);p(x2);p(o);p(c)
>
>   x1 = c; x2 = c; o = c
>   fmt.Printf("%T, %T, %T, %T\n", x1, x2, o, c)
>   p(x1);p(x2);p(o);p(c)
^

x2 (type T2) is assignable to the argument of p (type interface{}), but
when the assignment happens, the value loses the information that it
came from a value with interface type T2.  The o argument to p has
interface type interface{} and concrete type C, even though it came from
a value with interface type T2.

> }
>   
> func p(o interface{}) {
>   switch o.(type) {

A type switch uses the first case that can match (i.e.
type-assertibility, not assignability).  For the x2 case above, o still
only has interface type interface{} and concrete type C.  However C is
type-assertible to type T1, so the first case matches (and so do all the
others, except default, but the first matching case wins).

>   case T1: fmt.Println("T1")
>   case T2: fmt.Println("T2")
>   case C: fmt.Println("C")
>   case interface{}: fmt.Println("interface{}")
>   default: fmt.Println("?")
>   }
> }

It is also worth emphasizing that if you changed the argument to p from
interface{} to T2, the following snippet would still print "T1":

func main() {
var x2 T2
var c C
x2 = c
p(x2)
}

func p(o T2) {
// remainder of function as above
...
}

...Marvin

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Bakul Shah]

On Sun, 25 Feb 2018 09:25:42 + Jan Mercl <0xj...@gmail.com> wrote:
Jan Mercl writes:
> --f4f5e808e63ceebaa7056605faf5
> Content-Type: text/plain; charset="UTF-8"
> 
> On Sun, Feb 25, 2018 at 10:23 AM Bakul Shah  wrote:
> 
> > Why not case T2?
> 
> It does match T2 as well. The order of cases of the type switch maters:
> https://play.golang.org/p/nb28xHQP7oU

Duh! Thanks!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Jan Mercl]

On Sun, Feb 25, 2018 at 10:23 AM Bakul Shah  wrote:

> Why not case T2?

It does match T2 as well. The order of cases of the type switch maters:
https://play.golang.org/p/nb28xHQP7oU

-- 

-j

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Bakul Shah]

On Sun, 25 Feb 2018 01:01:08 -0800 Dave Cheney  wrote:
Dave Cheney writes:
> --=_Part_12529_340231507.1519549268925
> Content-Type: text/plain; charset="UTF-8"
> 
> Type C conforms to the T1 interface?
> 
> What did you expect?

C conforms to both T1 and T2.

var x2 T2
x2 = c 

switch x2.(type) matches case T1 -- this is what I find
strange. Why not case T2?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Float multiplication bug?

[Michael Jones]

This question is already answered, but i was on a plane and added a bit to
the printing and the comments. in case anyone ever refers to this thread in
the future, this is the better version of the program to run:
https://play.golang.org/p/EK0XMnMUKwv

On Fri, Feb 23, 2018 at 8:06 AM, Michael Jones 
wrote:

> One subtle thing is the difference between an ideal number, its
> floating-point representation, and its printed form.
>
> On Fri, Feb 23, 2018 at 5:46 AM,  wrote:
>
>> Thanks guys. That's very helpful.  I forgot that what I saw (and re-used)
>> as the "height" was not precise enough to make it comparable.
>>
>>
>> On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote:
>>>
>>>
>>>  Hello Everyone,
>>>
>>>  This looks like a Golang bug to me. What do you all think?
>>>
  I have this function ...
>>>
>>> func getArea(base, side int64) float64 {
 var height, fSide, area float64
 fSide = float64(side)
 halfBase := float64(base) / 2.0
 height = math.Sqrt(fSide*fSide - halfBase*halfBase)
 area = halfBase * height
 fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height,
 area)

>>>
>>>
 hb2 := 151414.5
 h2 := 262256.452301
 fmt.Printf("Area 2: %f\n", hb2 * h2)

>>>
>>>
 return area
 }
>>>
>>>
>>> When I call it with `result := getArea(302829, 302828)`,   I get this
>>> output ...
>>>
>>> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
 Area 2: 39709429596.929764
>>>
>>>
>>> I could see how some kind of rounding could produce the first Area
>>> value.  But in that case, why wouldn't Area2 be rounded as well?
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>



-- 
Michael T. Jones
michael.jo...@gmail.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Float multiplication bug?

[Michael Jones]

One subtle thing is the difference between an ideal number, its
floating-point representation, and its printed form.

On Fri, Feb 23, 2018 at 5:46 AM,  wrote:

> Thanks guys. That's very helpful.  I forgot that what I saw (and re-used)
> as the "height" was not precise enough to make it comparable.
>
>
> On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote:
>>
>>
>>  Hello Everyone,
>>
>>  This looks like a Golang bug to me. What do you all think?
>>
>>>  I have this function ...
>>
>> func getArea(base, side int64) float64 {
>>> var height, fSide, area float64
>>> fSide = float64(side)
>>> halfBase := float64(base) / 2.0
>>> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
>>> area = halfBase * height
>>> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height,
>>> area)
>>>
>>
>>
>>> hb2 := 151414.5
>>> h2 := 262256.452301
>>> fmt.Printf("Area 2: %f\n", hb2 * h2)
>>>
>>
>>
>>> return area
>>> }
>>
>>
>> When I call it with `result := getArea(302829, 302828)`,   I get this
>> output ...
>>
>> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
>>> Area 2: 39709429596.929764
>>
>>
>> I could see how some kind of rounding could produce the first Area
>> value.  But in that case, why wouldn't Area2 be rounded as well?
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Michael T. Jones
michael.jo...@gmail.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Tamás Gulácsi]

When you append to a slice with the append function, it just assigns the value 
to the len.th slot and increments len.
This is only possible, if the backing array is big enough. This backing array 
capacity is the slice's capacity, retrieved by cap.

If the capacity is not enough, a new, bigger backing array is allocated, 
everything is copied to it, plus the new element.

This allocation and copy costs cpu cycles and garbage collection time, so each 
time the backing array is doubled till 1024, then *1.25, but this is 
deterministic.

So if your program is deterministic, the backing array will have the capacity  
to hold the values for multiple cycles in a specific point in your program.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Sasan Rose]

Hi Jesse

Thank you very much. I guess that happens when you come to Go with a PHP 
background. I still have one question, why does it happen always on that 
iteration? Not the previous iterations?

On Tuesday, December 19, 2017 at 4:32:09 PM UTC+11, Jesse McNelis wrote:
>
> On Tue, Dec 19, 2017 at 4:10 PM, Sasan Rose  > wrote: 
> > Hi Jess 
> > 
> > Apologies for my bad example. Please kindly see my reply to Dave's post. 
> > Thanks 
>
> I fixed your example so that the slice called 'combination' isn't 
> shared with every slice in every iteration of the loop. 
> https://play.golang.org/p/s0WvBuZr_P 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Jesse McNelis]

On Tue, Dec 19, 2017 at 4:10 PM, Sasan Rose  wrote:
> Hi Jess
>
> Apologies for my bad example. Please kindly see my reply to Dave's post.
> Thanks

I fixed your example so that the slice called 'combination' isn't
shared with every slice in every iteration of the loop.
https://play.golang.org/p/s0WvBuZr_P

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Sasan Rose]

Hi Jess

Apologies for my bad example. Please kindly see my reply to Dave's post. 
Thanks

On Tuesday, December 19, 2017 at 2:43:50 PM UTC+11, Jesse McNelis wrote:
>
> On Tue, Dec 19, 2017 at 8:54 AM, Sasan Rose  > wrote: 
> > Please take a look at https://play.golang.org/p/BL4LUGk-lH 
>
> solutionNew = make([]int, 0) 
> solutionNew = append(solution, 2) 
>
> Is a strange thing to do, you create a new slice using make([]int, 0) 
> and then never use it. 
> perhaps you wanted to use copy()? 
>
>
> The problem you're encountering is slices can share backing arrays. 
> Each time you append to the slice called 'solution', you're modifying 
> the same backing array. 
>
> In your code: 
>
> /*You append 2 to solution creating a slice that points to the same 
> memory as 'solution'*/ 
>  solutionNew = append(solution, 2) 
>
> /* You append this slice to a slice called slice */ 
>  slice = append(slice, solutionNew) 
>
> /* You append a 4 to the same slice called 'solution' which shares 
> memory with slice you appended to your slice called 'slice' thus you 
> override the 2 you append to 'solution' with a 4*/ 
>  solutionNew = append(solution, 4) 
>
> /* You append the slice to 'slice' so now there are two slices in 
> 'slice' that refer to the same memory and thus have the same value */ 
>  slice = append(slice, solutionNew) 
>
>
> - Jesse 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Jesse McNelis]

On Tue, Dec 19, 2017 at 8:54 AM, Sasan Rose  wrote:
> Please take a look at https://play.golang.org/p/BL4LUGk-lH

solutionNew = make([]int, 0)
solutionNew = append(solution, 2)

Is a strange thing to do, you create a new slice using make([]int, 0)
and then never use it.
perhaps you wanted to use copy()?


The problem you're encountering is slices can share backing arrays.
Each time you append to the slice called 'solution', you're modifying
the same backing array.

In your code:

/*You append 2 to solution creating a slice that points to the same
memory as 'solution'*/
 solutionNew = append(solution, 2)

/* You append this slice to a slice called slice */
 slice = append(slice, solutionNew)

/* You append a 4 to the same slice called 'solution' which shares
memory with slice you appended to your slice called 'slice' thus you
override the 2 you append to 'solution' with a 4*/
 solutionNew = append(solution, 4)

/* You append the slice to 'slice' so now there are two slices in
'slice' that refer to the same memory and thus have the same value */
 slice = append(slice, solutionNew)


- Jesse

-- 
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.
For more options, visit https://groups.google.com/d/optout.