[go-nuts] Re: memclr optimazation does worse?

On Thursday, December 15, 2016 at 10:18:57 AM UTC+8, T L wrote: > > But if I changed the line > type MyInt int32 > to > type MyInt int > then again, the memclr version becomes slower, or no advantage, for cases > of slice lengths larger than 200. > Tried other ty

[go-nuts] Re: memclr optimazation does worse?

But if I changed the line type MyInt int32 to type MyInt int then again, the memclr version becomes slower, or no advantage, for cases of slice lengths larger than 200. On Thursday, December 15, 2016 at 10:05:23 AM UTC+8, T L wrote: > > > > On Wednesday, December 14, 2016 at 10:

Re: [go-nuts] weird?

aw which supports your case. Saying it's weird is not enough. > > Peter > > > On Saturday, December 10, 2016 at 5:37:25 AM UTC-5, T L wrote: >> >> >> >> On Saturday, December 10, 2016 at 6:20:00 PM UTC+8, peterGo wrote: >>> >>> TL, >

Re: [go-nuts] weird?

On Saturday, December 10, 2016 at 7:08:01 PM UTC+8, Konstantin Khomoutov wrote: > > On Sat, 10 Dec 2016 02:37:24 -0800 (PST) > T L <tapi...@gmail.com > wrote: > > [...] > > But the spec says a method M defined for type T is also a method of > > *T. In fact

Re: [go-nuts] weird?

On Saturday, December 10, 2016 at 6:47:43 PM UTC+8, Jan Mercl wrote: > > > > I know this. > > But the spec says a method M defined for type T is also a method of *T. > > In fact, it is not accurate. T.M and (*T).M have different signatures. > > Please cite the part of the specs > > I don't

Re: [go-nuts] weird?

; > cannot use age (type Age) as type *Age in argument to (*Age).CanDrink > > Peter > I know this. But the spec says a method M defined for type T is also a method of *T. In fact, it is not accurate. T.M and (*T).M have different signatures. > > On Saturday, December 10,

Re: [go-nuts] weird?

On Saturday, December 10, 2016 at 4:11:43 PM UTC+8, Axel Wagner wrote: > > On Sat, Dec 10, 2016 at 9:00 AM, T L <tapi...@gmail.com > > wrote: > >> >> >> On Saturday, December 10, 2016 at 3:42:34 PM UTC+8, Axel Wagner wrote: >>> >>> I do

Re: [go-nuts] weird?

be the same function. > > On Sat, Dec 10, 2016 at 8:17 AM, T L <tapi...@gmail.com > > wrote: > >> >> package main >> >> import "fmt" >> import "reflect" >> >> type Age int >> func (age Age) CanDrink() bo

[go-nuts] weird?

package main import "fmt" import "reflect" type Age int func (age Age) CanDrink() bool { age++ return age >= 18 } func main() { var age Age = 11 Age.CanDrink(age) // (*Age).CanDrink(age) // cannot use age (type Age) as type *Age in argument to (*Age).CanDrink

Re: [go-nuts] Are short variable declarations necessary?

On Wednesday, November 9, 2016 at 6:29:13 PM UTC+8, Dave Cheney wrote: > > There are already too many ways to declare and or assign a variable in Go. > Adding more is not a solution. how about to prefix a ~ before identifiers to avoid shadowing: func f() { a, err := 1, error.New("an

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

On Thursday, November 24, 2016 at 8:16:49 AM UTC+8, Ian Lance Taylor wrote: > > On Wed, Nov 23, 2016 at 3:49 PM, roger peppe > wrote: > > Ian, what you say is true, but is also true of types and other objects > too, > > I think. I found some interesting anomalies playing

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

On Thursday, November 24, 2016 at 1:30:55 AM UTC+8, Axel Wagner wrote: > > On Wed, Nov 23, 2016 at 4:30 PM, T L <tapi...@gmail.com > > wrote: > >> If two functions do completely different things, they mus be two >> different functions. >> > >

Re: [go-nuts] Why doens't function type support comparision but channel type does?

On Thursday, November 24, 2016 at 12:06:43 AM UTC+8, Jan Mercl wrote: > > On Wed, Nov 23, 2016 at 4:55 PM T L <tapi...@gmail.com > > wrote: > > > But we can't take addresses of formally declared functions and function > literals. > > Yes, so if you canno

Re: [go-nuts] Why doens't function type support comparision but channel type does?

On Wednesday, November 23, 2016 at 11:47:19 PM UTC+8, Jan Mercl wrote: > > On Wed, Nov 23, 2016 at 4:28 PM T L <tapi...@gmail.com > > wrote: > > > Predeclared functions, including inlined ones, can be viewed as > constants, which have not addresses. > > We

Re: [go-nuts] Why doens't function type support comparision but channel type does?

On Wednesday, November 23, 2016 at 11:47:19 PM UTC+8, Jan Mercl wrote: > > On Wed, Nov 23, 2016 at 4:28 PM T L <tapi...@gmail.com > > wrote: > > > Predeclared functions, including inlined ones, can be viewed as > constants, which have not addresses. > > We

Re: [go-nuts] Why doens't function type support comparision but channel type does?

On Wednesday, November 23, 2016 at 11:28:13 PM UTC+8, T L wrote: > > > > On Wednesday, November 23, 2016 at 11:18:02 PM UTC+8, Jan Mercl wrote: >> >> On Wed, Nov 23, 2016 at 3:30 PM T L <tapi...@gmail.com> wrote: >> >> > Then? >> >> T

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

; > One of the main reasons given for not making functions comparable, is that > there is no good, intuitive notion of what "equality" means in the face of > inlining and closures, so *no matter what behavior you choose*, people will > be confused. > > On Wed, Nov

[go-nuts] Re: Why doens't function type support comparision but channel type does?

On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler wrote: > > Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L: >> >> >> >> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote: >>> >>> Just one a

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

hat not lead to > people asking here, once a week, why (os.Open == os.Open) == false or > something like that? > No, I don't os.Open != os.Open, they are the same question, so they are equal. I just mean comparing different functions always returns false. > > On Wed, Nov 23,

[go-nuts] Re: Why doens't function type support comparision but channel type does?

On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote: > > Just one argument out of many: Closures. > x := 3 > f1 := func() int { > return x > } > f2 := func() int { return 3 } > // Is f1 == f2 ? > > x = 4 > // What now? Still f1 == f2? Or never equal? > > Any bad to think

Re: [go-nuts] Why doens't function type support comparision but channel type does?

On Wednesday, November 23, 2016 at 9:45:56 PM UTC+8, Jan Mercl wrote: > > On Wed, Nov 23, 2016 at 2:40 PM T L <tapi...@gmail.com > > wrote: > > Functions can be inlined. > > -- > > -j > Then? Is there any problem to think no two functions can be equal? -

[go-nuts] Why doens't function type support comparision but channel type does?

. -- 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] Are short variable declarations necessary?

On Wednesday, November 9, 2016 at 8:13:36 PM UTC+8, Jan Mercl wrote: > > On Wed, Nov 9, 2016 at 1:00 PM T L <tapi...@gmail.com > > wrote: > > > many? I see only two ones. > > v := expr > var v = expr > var v T > var v T = expr > the last 3 and fu

Re: [go-nuts] Are short variable declarations necessary?

On Wednesday, November 9, 2016 at 6:29:13 PM UTC+8, Dave Cheney wrote: > > There are already too many ways to declare and or assign a variable in Go. > Adding more is not a solution. many? I see only two ones. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Are short variable declarations necessary?

On Friday, October 21, 2016 at 11:26:46 PM UTC+8, T L wrote: > > > > On Friday, October 21, 2016 at 4:31:51 AM UTC+8, gri wrote: >> >> To answer the subject line question: No, short variable declarations are >> not technically necessary. We coul

Re: [go-nuts] Re: A question, simple for go team

On Saturday, October 22, 2016 at 11:59:55 PM UTC+8, Ian Lance Taylor wrote: > > On Sat, Oct 22, 2016 at 2:01 AM, T L <tapi...@gmail.com > > wrote: > > > > On Saturday, October 22, 2016 at 4:57:52 PM UTC+8, T L wrote: > >> > >> > >>

[go-nuts] Re: A question, simple for go team

On Saturday, October 22, 2016 at 4:57:52 PM UTC+8, T L wrote: > > > The string struct used internally is > > type stringStruct struct { > str unsafe.Pointer > len int > } > > When following f function is called and s is cleared, > how do go runtime

[go-nuts] A question, simple for go team

The string struct used internally is type stringStruct struct { str unsafe.Pointer len int } When following f function is called and s is cleared, how do go runtime knows the starting memory address of the old s.str is "a" instead of "c"? var s = "abcdefg"[2:5] // s.str should point

Re: [go-nuts] What is called reference values in Golang?

On Fri, Oct 21, 2016 at 8:20 AM, 'Alan Donovan' via golang-nuts < > golan...@googlegroups.com > wrote: > >> On 21 October 2016 at 11:15, T L <tapi...@gmail.com > wrote: >>> >>> On Friday, October 21, 2016 at 10:01:43 PM UTC+8, Ian Lance Taylor wrote:

Re: [go-nuts] What is called reference values in Golang?

On Friday, October 21, 2016 at 9:40:09 PM UTC+8, Ian Lance Taylor wrote: > > On Thu, Oct 20, 2016 at 10:47 PM, T L <tapi...@gmail.com > > wrote: > > > > On Friday, October 21, 2016 at 1:11:32 AM UTC+8, Ian Lance Taylor wrote: > >> > >> On Thu, Oc

[go-nuts] Re: URL prefix for Go's "present"

Do you want to host your talks under your own doamin? Please read the docs: https://github.com/golang/talks, (the present folder is here: https://github.com/golang/tools) You can deploy it on app engine. But the app is simple, it should be easy to deploy it elsewhere. On Friday, October 21,

Re: [go-nuts] What is called reference values in Golang?

On Friday, October 21, 2016 at 11:20:44 PM UTC+8, Alan Donovan wrote: > > On 21 October 2016 at 11:15, T L <tapi...@gmail.com > wrote: >> >> On Friday, October 21, 2016 at 10:01:43 PM UTC+8, Ian Lance Taylor wrote: >>> >>> On Fri, Oct 21, 2016 at 6:5

Re: [go-nuts] Are short variable declarations necessary?

ommon) use > case. > > - gri > > Thanks, gri, this is almost the answer I want. I still have two small questions about the short form. 1. would it be good to allow all identifiers in a short form are old ones (assume there is only one code block)? 2. would it be good/better t

Re: [go-nuts] What is called reference values in Golang?

ace/function. For example, like other languages, still use null for pointer zero values. > > The whole "call by reference" debate is fun but usually with beer... > > fre 21 okt. 2016 kl 15:39 skrev Ian Lance Taylor <ia...@golang.org > >: > >> On Thu, Oct 20,

Re: [go-nuts] What is called reference values in Golang?

On Friday, October 21, 2016 at 10:01:43 PM UTC+8, Ian Lance Taylor wrote: > > On Fri, Oct 21, 2016 at 6:52 AM, Henrik Johansson > wrote: > > The confusion I have had is rather with nilability. > > A channel can be nil even though it is not explicitly a pointer. > > It's

Re: [go-nuts] What is called reference values in Golang?

On Friday, October 21, 2016 at 1:11:32 AM UTC+8, Ian Lance Taylor wrote: > > On Thu, Oct 20, 2016 at 6:47 AM, T L <tapi...@gmail.com > > wrote: > > > > On Thursday, October 20, 2016 at 4:46:52 PM UTC+8, Dave Cheney wrote: > >> > >> What is a

Re: [go-nuts] What is called reference values in Golang?

On Thursday, October 20, 2016 at 10:34:41 PM UTC+8, T L wrote: > > > > On Thursday, October 20, 2016 at 9:58:46 PM UTC+8, T L wrote: >> >> >> >> On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote: >>> >>> I like Alan's "usef

Re: [go-nuts] What is called reference values in Golang?

On Thursday, October 20, 2016 at 9:58:46 PM UTC+8, T L wrote: > > > > On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote: >> >> I like Alan's "useful definition" of a semantically reference type, which >> involves shared mutable state.

[go-nuts] Re: Append consecutive slices, same underlying array

yes, you are right. You can file an issue at https://github.com/golang/go/issues On Thursday, October 20, 2016 at 9:11:14 PM UTC+8, Nick Patavalis wrote: > > Hi, > > It seems that the built-in append does not check for a situation like > the following, and needlessly copies data, when it could

Re: [go-nuts] What is called reference values in Golang?

On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote: > > I like Alan's "useful definition" of a semantically reference type, which > involves shared mutable state. > > About the string type, I also like the implementation detail that > > var string t = s > > is O(1) in memory and

Re: [go-nuts] What is called reference values in Golang?

years ago, in effect, to try > to stem these discussions. > Yes, I found many old docs and old web pages are still using the word "reference value". I think it is an unnecessary word. The concepts of values and pointer values are sufficient to understand Golang values well. > >

[go-nuts] Re: Golang should have a center packages index hosting like npm, rust crates

On Thursday, October 20, 2016 at 4:43:08 PM UTC+8, Dave Cheney wrote: > > T L, I often hear this comment when a central repo for Go is > proposed/suggested/requested. Are you able to give details of the things > you do not like about Maven/npm/rubygems central repos. The m

[go-nuts] Re: Golang should have a center packages index hosting like npm, rust crates

On Thursday, October 20, 2016 at 12:05:03 PM UTC+8, zixu mo wrote: > > Golang should have a center packages index hosting like npm, rust crates. > > > > For Rust : > https://crates.io/ > > For JS: > https://www.npmjs.com/ > > > For PHP > https://packagist.org/ > > For Ruby >

Re: [go-nuts] Are short variable declarations necessary?

On Thursday, October 20, 2016 at 3:25:18 AM UTC+8, Ian Lance Taylor wrote: > > On Wed, Oct 19, 2016 at 11:38 AM, Michael Jones > wrote: > > As in a number of previous questions, this one was asked poorly and the > answers dance all around the intention. I had decided

Re: [go-nuts] What is called reference values in Golang?

On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com wrote: > > On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote: >> >> On Wed, Oct 19, 2016 at 12:27 PM T L <tapi...@gmail.com> wrote: >> >> Nothing. The language specification d

Re: [go-nuts] What is called reference values in Golang?

On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com wrote: > > On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote: >> >> On Wed, Oct 19, 2016 at 12:27 PM T L <tapi...@gmail.com> wrote: >> >> Nothing. The language specification d

[go-nuts] Re: time.Parse : hour out of range

On Wednesday, October 19, 2016 at 11:49:52 AM UTC+8, Diego Medina wrote: > > Hi, > > From a 3rd party I get a file with time like 1503 or 900 (meaning 3:03PM > or 9:00 AM) > > so I thought I could use this format: > > https://play.golang.org/p/RKR71hTWGo > > x, err := time.Parse("1504", "900")

Re: [go-nuts] Are short variable declarations necessary?

ill. > > On Wed, Oct 19, 2016 at 11:24 AM, T L <tapi...@gmail.com > > wrote: > >> >> >> On Wednesday, October 19, 2016 at 5:43:48 AM UTC+8, Ian Lance Taylor >> wrote: >> >>> On Tue, Oct 18, 2016 at 7:50 AM, T L <tapi...@gmail.com>

[go-nuts] What is called reference values in Golang?

. -- 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] Are short variable declarations necessary?

On Wednesday, October 19, 2016 at 5:43:48 AM UTC+8, Ian Lance Taylor wrote: > > On Tue, Oct 18, 2016 at 7:50 AM, T L <tapi...@gmail.com > > wrote: > > > > On Tuesday, October 18, 2016 at 10:40:02 PM UTC+8, Ian Lance Taylor > wrote: > >> > >

Re: [go-nuts] Are short variable declarations necessary?

On Wednesday, October 19, 2016 at 6:06:22 AM UTC+8, Nyah Check wrote: > > Hi TL, > > I can't talk on behalf of the creators of the language; but from my > personal experience; it makes code more succinct and easier to write; > something more or less like "doing more with less" if you know what

Re: [go-nuts] Are short variable declarations necessary?

declaration. > It's part of the reason why Go is strongly typed yet doesn't fully feel > that way, and was one of the main design goals at first. > > Why the control statements require one, however, is something I wouldn't > know. > On Oct 18, 2016, at 10:50 AM,

[go-nuts] Are short variable declarations necessary?

alternative question, why followings are not accepted in syntax: if var x = 5; x > 3 { _ = x } for var x = range []int{0,1,2} { _ = x } switch var x = "abc"; x { default: _ = x } switch var x = (interface{}(true)).(type) {

Re: [go-nuts] Re: no ways to atomically read values, other than intergers, if unsafe.Pointer and atomic.Value are not considered?

On Tuesday, October 11, 2016 at 10:37:55 PM UTC+8, Ian Lance Taylor wrote: > > On Tue, Oct 11, 2016 at 7:29 AM, T L <tapi...@gmail.com > > wrote: > > More specifically, if I want to make the read/write of a pointer value > > atomically, > > then must the po

[go-nuts] no ways to atomically read values, other than intergers, if unsafe.Pointer and atomic.Value are not considered?

package main import "unsafe" import "sync/atomic" type T struct { a *int // no ways?! b unsafe.Pointer } func (t T) A() *int { // cannot take the address of unsafe.Pointer(t.a) //return (*int)(atomic.LoadPointer((t.a))) return t.a // no ways to read t.a atomically

Re: [go-nuts] spec:

Thanks for the explanation. On Tuesday, October 11, 2016 at 12:55:06 AM UTC+8, Ian Lance Taylor wrote: > > On Mon, Oct 10, 2016 at 9:51 AM, T L <tapi...@gmail.com > > wrote: > > > > On Tuesday, October 11, 2016 at 12:19:10 AM UTC+8, Ian Lance Taylor > wrote: &

Re: [go-nuts] spec:

On Tuesday, October 11, 2016 at 12:19:10 AM UTC+8, Ian Lance Taylor wrote: > > On Mon, Oct 10, 2016 at 8:39 AM, T L <tapi...@gmail.com > > wrote: > > In the section of go spec: > > https://golang.org/ref/spec#Uniqueness_of_identifiers, it says: > >

Re: [go-nuts] spec:

On Tuesday, October 11, 2016 at 12:21:01 AM UTC+8, Jan Mercl wrote: > > On Mon, Oct 10, 2016 at 6:01 PM Paul Borman > wrote: > > > In your representation, P means "identifiers are different", so the > resulting false means the identifiers are the same, which is what the OP

[go-nuts] spec:

In the section of go spec: https://golang.org/ref/spec#Uniqueness_of_identifiers, it says: Two identifiers are different if they are spelled differently, or if they appear in different packages and are not exported

[go-nuts] Re: what's the difference between Golang and Java about interface?

On Saturday, October 8, 2016 at 9:14:34 PM UTC+8, Fei Ding wrote: > > Recently I've been asked a question which is, what's the difference > between Golang and Java about *interface*? > > > I know there are some 'syntax-sugar level' differences, what I am > interested is anything beneath the

[go-nuts] Re: what's the difference between Golang and Java about interface?

In golang, if a concrete type embeds an interface type, the concrete type must implement this interface type. package main type I interface { IsZero() bool } type T struct { I } var i I = T{} // implemention assertion ok func main(){ } On Saturday, October 8, 2016 at 9:14:34 PM

[go-nuts] Re: what's the difference between Golang and Java about interface?

On Saturday, October 8, 2016 at 9:14:34 PM UTC+8, Fei Ding wrote: > > Recently I've been asked a question which is, what's the difference > between Golang and Java about *interface*? > > > I know there are some 'syntax-sugar level' differences, what I am > interested is anything beneath the

Re: [go-nuts] How to define two identical named types?

On Monday, October 3, 2016 at 4:59:26 PM UTC+8, T L wrote: > > > > On Monday, October 3, 2016 at 2:42:30 PM UTC+8, Axel Wagner wrote: >> >> Which would imply that something like this >> type ( >> Foo int >> Foo int >> ) >> might

Re: [go-nuts] How to define two identical named types?

same type-decl in texts. I really don't know my English understanding is right or not, now, again. > > On Mon, Oct 3, 2016 at 7:26 AM, T L <tapi...@gmail.com > > wrote: > >> >> >> On Monday, October 3, 2016 at 1:52:10 AM UTC+8, Marvin Renich wrote: >>> &

Re: [go-nuts] How to define two identical named types?

> comparison would need to equal false (as the types would not be identical). > > I don't think there is any ambiguity or lack of clarity here. > > On Sun, Oct 2, 2016 at 7:08 AM, T L <tapi...@gmail.com > > wrote: > >> >> >> On Sunday, October 2, 2016

Re: [go-nuts] How to define two identical named types?

On Sunday, October 2, 2016 at 12:24:24 PM UTC+8, Ian Lance Taylor wrote: > > On Sat, Oct 1, 2016 at 9:21 PM, T L <tapi...@gmail.com > > wrote: > > > > On Sunday, October 2, 2016 at 12:17:05 PM UTC+8, Ian Lance Taylor wrote: > >> > >> On Sat, Oc

[go-nuts] Re: vender folder problem

On Sunday, October 2, 2016 at 12:07:06 PM UTC+8, topiya...@gmail.com wrote: > > I have two import packages and have it in vendor dir. > > kitprometheus "github.com/go-kit/kit/metrics/prometheus" > > stdprometheus "github.com/prometheus/client_golang/prometheus" > > > error while compile with

Re: [go-nuts] How to define two identical named types?

On Sunday, October 2, 2016 at 11:34:41 AM UTC+8, Matt Harden wrote: > > I do think that T L has a point. The spec defines the syntax of the > language, and TypeSpec refers to a syntactical construct. It is not > possible in the syntax of the language to create two named types that

Re: [go-nuts] How to define two identical named types?

On Sunday, October 2, 2016 at 2:37:23 AM UTC+8, Jan Mercl wrote: > > > On Sat, Oct 1, 2016 at 7:56 PM T L <tapi...@gmail.com > > wrote: > > > Then could you provide an example two identical custom named types > originate in the same TypeSpec? > > Answer is i

Re: [go-nuts] How to define two identical named types?

; It *is* possible to define two named types with the same name (which are > not identical according to the spec): > https://play.golang.org/p/PmkcvdNQnx > > On Sat, Oct 1, 2016 at 5:03 PM, Jan Mercl <0xj...@gmail.com > > wrote: > >> On Sat, Oct 1, 2016 at 4:28 PM T

Re: [go-nuts] How to define two identical named types?

On Sunday, October 2, 2016 at 12:38:00 AM UTC+8, Ian Lance Taylor wrote: > > On Sat, Oct 1, 2016 at 8:55 AM, T L <tapi...@gmail.com > > wrote: > > > > On Saturday, October 1, 2016 at 11:29:35 PM UTC+8, Axel Wagner wrote: > >> > >> It *is* pos

[go-nuts] Re: go/types equality rules are incredibly confusing

On Sunday, October 2, 2016 at 12:25:02 AM UTC+8, Nate Finch wrote: > > That's a tutorial, not documentation. It would have been useful to have > that information in the godoc. > > I agree it was a mistake to use a Type as a map key, but the fact that it > does work for some Types was what

[go-nuts] Re: go/types equality rules are incredibly confusing

On Saturday, October 1, 2016 at 11:50:24 PM UTC+8, Nate Finch wrote: > > There are a couple details to how go/types.Type values compare that I > think need better documentation. Ideally there would be some programmatic > improvement, but that might not be possible. > > First: go/types.Type

Re: [go-nuts] How to define two identical named types?

On Saturday, October 1, 2016 at 10:07:02 PM UTC+8, Jan Mercl wrote: > > > > but we even don't know how the builtin byte and uint8 are defined? > > Yes we know, see: https://golang.org/ref/spec#Numeric_types > I know this byte and uint8 are identical in syntax. But they are not defined with

Re: [go-nuts] How to define two identical named types?

On Saturday, October 1, 2016 at 6:09:52 PM UTC+8, Jan Mercl wrote: > > > On Sat, Oct 1, 2016 at 12:03 PM T L <tapi...@gmail.com > > wrote: > > > I don't think it is meaningless byte and uint8 share the same type spec. > > Great. > > > I just

Re: [go-nuts] How to define two identical named types?

On Saturday, October 1, 2016 at 5:00:53 PM UTC+8, Jan Mercl wrote: > > > > On Sat, Oct 1, 2016, 10:54 T L <tapi...@gmail.com > wrote: > >> >> >> Then how are they defined? >> > > Discussed earlier in this thread: they are pre

Re: [go-nuts] How to define two identical named types?

On Saturday, October 1, 2016 at 4:34:08 PM UTC+8, Jan Mercl wrote: > > > > On Sat, Oct 1, 2016, 10:25 T L <tapi...@gmail.com > wrote: > >> >> >> On Saturday, October 1, 2016 at 4:02:14 PM UTC+8, Jan Mercl wrote: >> >>> On Sat

Re: [go-nuts] How to define two identical named types?

On Saturday, October 1, 2016 at 4:02:14 PM UTC+8, Jan Mercl wrote: > > On Sat, Oct 1, 2016 at 9:48 AM T L <tapi...@gmail.com > > wrote: > > > If no two custom named types are identical, why spec says that? > > Because identical named types do exists. You have alrea

[go-nuts] Re: Any plan on improving Go's escape analysis?

On Saturday, October 1, 2016 at 3:47:09 PM UTC+8, bronze man wrote: > > When I call `fmt.Println(1,2) `, I expect all the interfaces of the > arguments should alloc on stack so that the garbage collection part will > use less cpu time, but currently it is alloc on heap.Because I found that I

Re: [go-nuts] How to define two identical named types?

On Saturday, October 1, 2016 at 3:31:00 PM UTC+8, Jan Mercl wrote: > > > > On Sat, Oct 1, 2016, 09:13 T L <tapi...@gmail.com > wrote: > >> In Go spec, https://golang.org/ref/spec#Type_identity, it says: >> >> Two named types <https://golang.org/ref/s

[go-nuts] How to define two identical named types?

In Go spec, https://golang.org/ref/spec#Type_identity, it says: Two named types are identical if their type names originate in the same TypeSpec . But, in my impression, in Golang, there are only two pair types

Re: [go-nuts] why this?

On Thursday, September 29, 2016 at 11:48:34 PM UTC+8, andrey mirtchovski wrote: > > > I just expect type asserting on a non-nil interface value shouldn't > panic. > > of course it should panic if the interface holds an unexpected value > and you're not checking for correctness with the

Re: [go-nuts] why this?

On Thursday, September 29, 2016 at 8:46:14 PM UTC+8, Konstantin Khomoutov wrote: > > On Thu, 29 Sep 2016 00:25:23 -0700 (PDT) > T L <tapi...@gmail.com > wrote: > > > > > I just want to understand what is the deep reason for the syntax > > > > incon

[go-nuts] Re: Licenses

On Thursday, September 29, 2016 at 4:24:51 PM UTC+8, T L wrote: > > > > On Thursday, September 29, 2016 at 4:12:41 PM UTC+8, dja...@gmail.com > wrote: >> >> Hi, >> May be OT, but: >> >> Can i translate some GPLv2 licensed C code to GO, and p

[go-nuts] Re: Licenses

On Thursday, September 29, 2016 at 4:12:41 PM UTC+8, dja...@gmail.com wrote: > > Hi, > May be OT, but: > > Can i translate some GPLv2 licensed C code to GO, and publish it under > BSD new license ? > Code comments are from original C code. > no,

Re: [go-nuts] why this?

On Thursday, September 29, 2016 at 3:31:46 PM UTC+8, Dave Cheney wrote: > > Sorry, I misspoke, this logic does not apply to map lookup, they are > unrelated other than having a one arg and two arg form. :) yes, that is what the weirdness and inconsistency is. -- You received this message

Re: [go-nuts] why this?

On Thursday, September 29, 2016 at 3:21:26 PM UTC+8, Volker Dobler wrote: > > Am Donnerstag, 29. September 2016 07:02:26 UTC+2 schrieb T L: >> >> I know of the syntax in spec. >> I just want to understand what is the deep reason for the syntax >> inconsistency bet

Re: [go-nuts] why this?

On Thursday, September 29, 2016 at 1:07:17 PM UTC+8, andrey mirtchovski wrote: > > > I just want to understand what is the deep reason for the syntax > > inconsistency between map index and type assert. > > a map is fully typed at compile time. even if its key is of type > interface{} the

Re: [go-nuts] why this?

On Thursday, September 29, 2016 at 3:10:46 PM UTC+8, Dave Cheney wrote: > > Which of these would you prefer happened instead? > > * A failed type assertion always panic'd > * A failed type assertion never panic'd and instead returned the zero > value, as the map lookup does > * Something else >

Re: [go-nuts] why this?

ke it work syntactically as the type assertion >> would make it weird. >> >> On Thu, Sep 29, 2016, 07:02 T L <tapi...@gmail.com > wrote: >> >>> >>> >>> On Thursday, September 29, 2016 at 12:56:57 PM UTC+8, Micky wrote: >>>> >>>> Th

Re: [go-nuts] why this?

On Thursday, September 29, 2016 at 1:31:41 PM UTC+8, Ian Lance Taylor wrote: > > On Wed, Sep 28, 2016 at 10:02 PM, T L <tapi...@gmail.com > > wrote: > > > > On Thursday, September 29, 2016 at 12:56:57 PM UTC+8, Micky wrote: > >> > >> The reas

Re: [go-nuts] why this?

It is really weird that the behavior of type assertion depends on whether the second OK result value is received or not. > On Thu, Sep 29, 2016, 07:02 T L <tapi...@gmail.com > wrote: > >> >> >> On Thursday, September 29, 2016 at 12:56:57 PM UTC+8, Micky wrote: >>>

Re: [go-nuts] why this?

time > panic <https://golang.org/ref/spec#Run_time_panics> occurs." > > Here "hold" means if it succeeds. > > I know of the syntax in spec. I just want to understand what is the deep reason for the syntax inconsistency between map index and type assert. >

[go-nuts] Re: Just because we can add multiple logical processors for the scheduler to use doesn’t mean we should

Usually, GOMAXPROCS==NumberAvaliableCpuCores (the default value since go1.5) will get the best performance. For some special cases, a smaller GOMAXPROCS value will perform better. But A GOMAXPROCS value larger than NumberAvaliableCpuCores will always decrease the performance, IMO. On Friday,

[go-nuts] Re: Can't understand untyped constant behavior

On Friday, September 9, 2016 at 12:15:53 AM UTC+8, T L wrote: > > Although x and y's possible types include float32, there are two steps in > "var f float32 = x / y". > The first one is "x / y", for both default type of x and y is int, so the > result is 1.

[go-nuts] Re: Can't understand untyped constant behavior

Although x and y's possible types include float32, there are two steps in "var f float32 = x / y". The first one is "x / y", for both default type of x and y is int, so the result is 1. The second step is "var f float32 = 1". This is it. If you change 5 to 5.0, or change 3 to 3.0, then the

Re: [go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

On Thursday, September 8, 2016 at 10:57:10 PM UTC+8, Ian Lance Taylor wrote: > > On Thu, Sep 8, 2016 at 7:21 AM, T L <tapi...@gmail.com > > wrote: > > > > On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote: > >> > >> On Thu,

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

On Thursday, September 8, 2016 at 10:50:36 PM UTC+8, Ian Lance Taylor wrote: > > On Thu, Sep 8, 2016 at 3:46 AM, T L <tapi...@gmail.com > > wrote: > > > > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor > wrote: > >> > &g

Re: [go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote: > > On Thu, Sep 8, 2016 at 3:32 PM T L <tapi...@gmail.com > > wrote: > > > With the enough initial size, the underlying hashtable of the new map > will never need to be realloced in the whole co

[go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

With the enough initial size, the underlying hashtable of the new map will never need to be realloced in the whole copy process. -- 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,

<    1   2   3   4   5   6   >