[go-nuts] Re: proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

On Saturday, April 21, 2018 at 9:30:22 AM UTC-4, b97...@gmail.com wrote: > > var someInterfaceValue interface{} > switch { > case someInterfaceValue: // proposal: compile error: non-bool used as > condition > case someInterfaceValue == true: // OK > } > > Sometimes carefulness is just not

[go-nuts] Re: how does SSA CSE (common subexpression elimination) work?

In fact, CSE works here. package main import ( "testing" ) var v1a int func Benchmark_CSE_Case_1a(b *testing.B) { b.ResetTimer() for i := 0; i < b.N; i++ { var x, y, z = 123, 456, 789 v1a = (y+z) / x + (y+z) / x + (y+z) / x } } func Benchmark_CSE_Case_1b(b

[go-nuts] Re: how does SSA CSE (common subexpression elimination) work?

sorry, my mistake. I run another benchmark. This benchmark fails to compile. On Saturday, March 10, 2018 at 1:27:17 PM UTC-5, di...@veryhaha.com wrote: > > It looks CSE doesn't work for the following case. > > package main > > import ( > "testing" > ) > > var v1a int > func

[go-nuts] how does SSA CSE (common subexpression elimination) work?

It looks CSE doesn't work for the following case. package main import ( "testing" ) var v1a int func Benchmark_CSE_Case_1a(b *testing.B) { s := make([]Element, N) b.ResetTimer() for i := 0; i < b.N; i++ { var x, y, z = 123, 456, 789 v1a = (y+z) / x + (y+z) / x +

Re: [go-nuts] Are the semicolons rules some weird?

On Thursday, March 8, 2018 at 12:36:19 PM UTC-5, Ian Lance Taylor wrote: > > On Thu, Mar 8, 2018 at 9:13 AM, > wrote: > > > > On Thursday, March 8, 2018 at 11:49:18 AM UTC-5, Ian Lance Taylor wrote: > >> > >> On Thu, Mar 8, 2018 at 8:43 AM,

Re: [go-nuts] Are the semicolons rules some weird?

btw, are there any cases a semicolon may be omitted before a closing ")"? On Thursday, March 8, 2018 at 11:49:18 AM UTC-5, Ian Lance Taylor wrote: > > On Thu, Mar 8, 2018 at 8:43 AM, > wrote: > > > > There are two semicolon rules in Go spec: > >

Re: [go-nuts] Are the semicolons rules some weird?

On Thursday, March 8, 2018 at 11:49:18 AM UTC-5, Ian Lance Taylor wrote: > > On Thu, Mar 8, 2018 at 8:43 AM, > wrote: > > > > There are two semicolon rules in Go spec: > > https://golang.org/ref/spec#Semicolons > > The first one states how a semicolon will be

[go-nuts] Are the semicolons rules some weird?

There are two semicolon rules in Go spec: https://golang.org/ref/spec#Semicolons The first one states how a semicolon will be automatically inserted, however, the second one states how a semicolon can be omitted. Isn't more consistent to modify the second one to the following description? To

Re: [go-nuts] Re: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

On Wednesday, March 7, 2018 at 6:02:58 PM UTC-5, Ian Lance Taylor wrote: > > On Wed, Mar 7, 2018 at 1:36 PM, > wrote: > > > > On Wednesday, March 7, 2018 at 4:26:19 PM UTC-5, di...@veryhaha.com > wrote: > >> > >> get it almost. > >> > >> But I feel > >> > >>

Re: [go-nuts] Re: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

On Wednesday, March 7, 2018 at 4:26:19 PM UTC-5, di...@veryhaha.com wrote: > > get it almost. > > But I feel > > var v = float32(1< is a little different to > var v float32 = 1< > > For the former one, we think "1" can be assumed as an "int". > But anyway, I get the main point of

Re: [go-nuts] Re: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

get it almost. But I feel var v = float32(1< On Wed, Mar 7, 2018 at 12:54 PM, Volker Dobler > wrote: > > Looks suspicious. Without crosschecking the Spec: Might be > > a bug. File an issue? > > It's not a bug.

[go-nuts] why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

var s uint = 33 var u2 = float64(1>>s) // illegal: 1 has type float64, cannot shift -- 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

[go-nuts] Re: Why gc compiler treat slice and custom type differently in garbage collection?

On Monday, March 5, 2018 at 10:34:35 AM UTC-5, Volker Dobler wrote: > > Your two programs are not the same. > Try fmt.Println(bs[0]) instead of len(bs) in the > first one. > > V. > Yes, you are right. They are different. Their behaviors should be compile dependent. > > On Monday, 5 March

[go-nuts] Why gc compiler treat slice and custom type differently in garbage collection?

Slice: package main import "fmt" import "runtime" func printMemStat(gcFirstly bool) { if gcFirstly { runtime.GC() } var stat runtime.MemStats runtime.ReadMemStats() println(stat.Alloc) } func main() { bs := make([]int, 100) printMemStat(false) //

Re: [go-nuts] should the reflect docs explain what do the Data fields mean in SliceHeader and StringHeader?

On Thursday, March 1, 2018 at 1:19:03 PM UTC-5, Ian Lance Taylor wrote: > > On Thu, Mar 1, 2018 at 9:08 AM, > wrote: > > If not, it is hard to use them in meaningful ways. > > The docs already say that the each type "cannot be used safely or > portably and its

Re: [go-nuts] Re: When an object is KeepAlived, will other objects referenced by it also be KeepAlived?

On Thursday, March 1, 2018 at 1:16:45 PM UTC-5, Ian Lance Taylor wrote: > > On Thu, Mar 1, 2018 at 9:04 AM, > wrote: > > > > Is the KeepAlive call in the following example essential? and > sufficient? > > > > func ByteSlice2String(bs []byte) (str string) { > >

Re: [go-nuts] copy is not very essential function? It can always be simulated by append?

On Thursday, March 1, 2018 at 12:46:13 PM UTC-5, Axel Wagner wrote: > > There is another significant difference > between append and copy, which is > that copy only copies the minimum number of elements in either slice. So, > if you want to simulate

[go-nuts] should the reflect docs explain what do the Data fields mean in SliceHeader and StringHeader?

If not, it is hard to use them in meaningful ways. -- 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,

[go-nuts] Re: When an object is KeepAlived, will other objects referenced by it also be KeepAlived?

Is the KeepAlive call in the following example essential? and sufficient? func ByteSlice2String(bs []byte) (str string) { sliceHdr := (*reflect.SliceHeader)(unsafe.Pointer()) strHdr := (*reflect.StringHeader)(unsafe.Pointer()) strHdr.Len = sliceHdr.Len strHdr.Data = sliceHdr.Data

Re: [go-nuts] copy is not very essential function? It can always be simulated by append?

On Thursday, March 1, 2018 at 11:50:53 AM UTC-5, andrey mirtchovski wrote: > > > I don't know that. append was not in Go 1.0? > > Go the language was opened to the world on Nov 10, 2009. Go 1.0 was > released 28 March 2012. > > Append appeared on Oct 27, 2010: > >

Re: [go-nuts] copy is not very essential function? It can always be simulated by append?

On Thursday, March 1, 2018 at 11:26:02 AM UTC-5, Jan Mercl wrote: > > > On Thu, Mar 1, 2018 at 5:13 PM wrote: > > > _ = append(b[1:1], b[:len(b)-1]...) > > Bad reading, my fault. > > Anyway, I think it should now be clear that append depends on the > 'inteligence' of copy

[go-nuts] When an object is KeepAlived, will other objects referenced by it also be KeepAlived?

For example, func f(s []byte) { // Will the the KeepAlive call make sure the underlying bytes // of s will not garbage collected for sure? runtime.KeepAlive() } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] copy is not very essential function? It can always be simulated by append?

yes On Thursday, March 1, 2018 at 11:14:24 AM UTC-5, Val wrote: > > Jan, I think OP meant https://play.golang.org/p/_fuSb34q_ex -- 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,

Re: [go-nuts] copy is not very essential function? It can always be simulated by append?

On Thursday, March 1, 2018 at 11:08:09 AM UTC-5, Jan Mercl wrote: > > On Thu, Mar 1, 2018 at 4:50 PM wrote: > > > copy(a[1:], a) is equivalent to _ = append(s[1:1], s[:len(s)-1]...) > > https://play.golang.org/p/uiz2ANSxjbA > > If b = append(b[1:1], b[:len(b)-1]...) is

Re: [go-nuts] copy is not very essential function? It can always be simulated by append?

On Thursday, March 1, 2018 at 10:38:20 AM UTC-5, Jan Mercl wrote: > > On Thu, Mar 1, 2018 at 4:28 PM wrote: > > > is the statement right? > > It depends on the POV. I see copy as more fundamental than append. It's > easy to write append using copy, not exactly trivial the

[go-nuts] copy is not very essential function? It can always be simulated by append?

is the statement right? -- 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

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Monday, February 26, 2018 at 11:21:43 PM UTC-5, Ian Lance Taylor wrote: > > On Mon, Feb 26, 2018 at 7:20 PM, > wrote: > > > > On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor > wrote: > >> > >> On Mon, Feb 26, 2018 at 9:42 AM,

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor wrote: > > On Mon, Feb 26, 2018 at 9:42 AM, > wrote: > > > > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: > >> > >> On 26 Feb 2018, at 18:21, "di...@veryhaha.com"

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: > > On 26 Feb 2018, at 18:21, "di...@veryhaha.com " < > di...@veryhaha.com > wrote: > > On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: > <#34A5B26F-AB6C-4559-A17D-D8137AC52784@kastelo.net_> >

Re: [go-nuts] Is there some kind of memory write protection mechanism?

So, the sync/atomic package is possible to break tomorrow? On Monday, February 26, 2018 at 12:24:35 PM UTC-5, Andy Balholm wrote: > > Oops. I left out a couple words. I meant “does not keep”. > > Andy > > > On Feb 26, 2018, at 9:23 AM, Andy Balholm > wrote: > > > >

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: > > On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: > > > Will the "sync/atomic" package get broken? > This atomic package imports unsafe. > > > If changes to unsafe break sync/atomic it’s up to the Go team to fix >

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Sunday, February 25, 2018 at 7:38:22 PM UTC-5, Rob 'Commander' Pike wrote: > > The main rule about unsafe is that your program might work or might not. > There are no guarantees either way. That's why it's called 'unsafe' and why > you shouldn't use it. Your program that 'works' today

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Sunday, February 25, 2018 at 10:01:44 AM UTC-5, Jan Mercl wrote: > > > On Sun, Feb 25, 2018 at 3:20 PM wrote: > > > I think the unsafe rules allow this. > > Yes, but using unsafe provides no guarantees about writable memory. > > > I never expect it will crash, for I

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Sunday, February 25, 2018 at 8:57:53 AM UTC-5, Jan Mercl wrote: > > On Sun, Feb 25, 2018 at 2:29 PM wrote: > > > Why does the following program crash? > > Because the program attempts to write to the R/O text segment. Why is it > doing that? > Yes. I will not do this

[go-nuts] Is there some kind of memory write protection mechanism?

Why does the following program crash? package main import "fmt" import "unsafe" import "reflect" func main() { s := "keep" hdr := (*reflect.StringHeader)(unsafe.Pointer()) byteSequence := (*byte)(unsafe.Pointer(hdr.Data)) fmt.Println(*byteSequence) // k *byteSequence = 'j'

Re: [go-nuts] Why is the omitted expression in a swtich code block a typed bool "true"?

On Friday, February 2, 2018 at 10:45:58 AM UTC-5, Axel Wagner wrote: > > From the spec: > > >> If the switch expression evaluates to an untyped constant, it is first >> converted to its default type; if it is an untyped boolean value, it is >> first converted to type bool. The predeclared

Re: [go-nuts] Why is the omitted expression in a swtich code block a typed bool "true"?

On Friday, February 2, 2018 at 10:37:24 AM UTC-5, di...@veryhaha.com wrote: > > > > On Friday, February 2, 2018 at 10:27:04 AM UTC-5, Ian Lance Taylor wrote: >> >> On Fri, Feb 2, 2018 at 7:10 AM, wrote: >> > >> > Why not make it untyped? >> > >> > package main >> > >>

Re: [go-nuts] Why is the omitted expression in a swtich code block a typed bool "true"?

On Friday, February 2, 2018 at 10:37:24 AM UTC-5, di...@veryhaha.com wrote: > > > > On Friday, February 2, 2018 at 10:27:04 AM UTC-5, Ian Lance Taylor wrote: >> >> On Fri, Feb 2, 2018 at 7:10 AM, wrote: >> > >> > Why not make it untyped? >> > >> > package main >> > >>

Re: [go-nuts] Why is the omitted expression in a swtich code block a typed bool "true"?

On Friday, February 2, 2018 at 10:27:04 AM UTC-5, Ian Lance Taylor wrote: > > On Fri, Feb 2, 2018 at 7:10 AM, > wrote: > > > > Why not make it untyped? > > > > package main > > > > type T bool > > > > func f() T {return T(false)} > > > > func main() { > >

[go-nuts] Re: Why is the omitted expression in a swtich code block a typed bool "true"?

Looks the non-omitted "true" is also a typed value of "bool" type. package main type T bool func f() T {return T(false)} func main() { switch true { case f(): // invalid case f() in switch (mismatched types T and bool) } } On Friday, February 2, 2018 at 10:11:31 AM UTC-5,

[go-nuts] Why is the omitted expression in a swtich code block a typed bool "true"?

Why not make it untyped? package main type T bool func f() T {return T(false)} func main() { switch { case f(): // invalid case f() in switch (mismatched types T and bool) } } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] Re: "type MyByte byte", then how to convert []MyByte to []byte so that I can use bytes.Xyz functions for []MyByte?

On Wednesday, January 24, 2018 at 8:35:25 AM UTC-5, Volker Dobler wrote: > > See https://golang.org/doc/faq#convert_slice_with_same_underlying_type > > On Wednesday, 24 January 2018 13:57:59 UTC+1, di...@veryhaha.com wrote: >> >> except unsafe ways. >> > > Yes: explicit loop. > > Why did you do

[go-nuts] "type MyByte byte", then how to convert []MyByte to []byte so that I can use bytes.Xyz functions for []MyByte?

except unsafe ways. -- 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

Re: [go-nuts] Is there a mistake in the "Expression statements" section of Go spec?

On Sunday, January 14, 2018 at 10:14:21 AM UTC-5, Axel Wagner wrote: > > Why not? The linked Expression section (more specifically, the Expression > *rule*) defines the format of expressions. An expression statement allows > you to use any expression also as a statement; this is important,

Re: [go-nuts] Re: Is my understanding on numeric literals right?

On Friday, January 12, 2018 at 9:00:34 AM UTC-5, di...@veryhaha.com wrote: > > > > On Friday, January 12, 2018 at 5:11:10 AM UTC-5, Axel Wagner wrote: >> >> Hm, this thread has actually opened up a question I don't have a good >> answer to. >> >> On Fri, Jan 12, 2018 at 9:47 AM,

[go-nuts] Re: How golang garbage collector works

https://blog.golang.org/go15gc On Thursday, January 11, 2018 at 10:50:24 AM UTC-5, golangguy wrote: > > Hi > > I am new to golang, and had background in C/C++ , can you some one give me > information/explanation about how garbage collectors in golang works ? > > Thanks, > > -- You received

Re: [go-nuts] Re: Is my understanding on numeric literals right?

On Friday, January 12, 2018 at 5:11:10 AM UTC-5, Axel Wagner wrote: > > Hm, this thread has actually opened up a question I don't have a good > answer to. > > On Fri, Jan 12, 2018 at 9:47 AM, wrote: > >> then can I say >> an untyped rune literal/constant is representable

Re: [go-nuts] Re: Is my understanding on numeric literals right?

then can I say an untyped rune literal/constant is representable int type for sure. an untyped interger literal/constant is representable float64 type for sure. an untyped floating-point literal/constant is representable complex128 type for sure. On Friday, January 12, 2018 at 2:42:20 AM UTC-5,

Re: [go-nuts] Re: Is my understanding on numeric literals right?

On Friday, January 12, 2018 at 2:42:20 AM UTC-5, Axel Wagner wrote: > > What do you mean by "potential type"? There is no such concept. > > The spec is pretty clear, on the > subject, IMO. There is also this blog post >

[go-nuts] Re: Is my understanding on numeric literals right?

or an untype literal who has a *rune* potential type must also has an *int* potential type. an untype literal who has an *int* potential type must also has a *float64* potential type. an untype literal who has a *float64* potential type must also has a *complex128* potential type. On Friday,

[go-nuts] Is my understanding on numeric literals right?

An untyped rune literal/constant must have a popential int type. An untyped interger literal/constant must have a popential float64 type. An untyped floating-point literal/constant must have a popential complex128 type. -- You received this message because you are subscribed to the Google

Re: [go-nuts] Is there a formal document explain the package search orders in Golang?

On Saturday, December 3, 2016 at 5:31:57 AM UTC+8, Ian Lance Taylor wrote: > > On Fri, Dec 2, 2016 at 11:24 AM, gd > wrote: > > It looks, for the official compiler, if the main package is under > GOPATH, > > then the order is: > > 1. the vendor folder > > 2. the

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

On Thursday, November 10, 2016 at 1:23:33 AM UTC+8, Marvin Renich wrote: > > * T L [161109 11:57]: > > yes, := can be avoided totally. > > but := really has some benefits. > > > > The contradiction is the short form is 80% good with 20% bad side > effects. > > I

Re: [go-nuts] Is there a way to check if all pending finalizers have been executed?

On Saturday, October 15, 2016 at 6:37:08 PM UTC+8, Hotei wrote: > > re "meaningfullness" - I think he's saying that a finalizer for a function > called in a goroutine might not run if main() quits first, intentionally or > otherwise. You can of course check for this specific case by making

Re: [go-nuts] Is there a way to check if all pending finalizers have been executed?

On Saturday, October 15, 2016 at 8:18:04 AM UTC+8, Ian Lance Taylor wrote: > > On Fri, Oct 14, 2016 at 4:08 PM, 'Peter Lam' via golang-nuts > wrote: > > Is there someway to wait for all pending finalizers to be run? > > Not in general, no. Conceptually it doesn't

Re: [go-nuts] don't understand the comment in spec Type assertions section

On Friday, October 14, 2016 at 1:33:52 AM UTC+8, di...@veryhaha.com wrote: > > > > On Friday, October 14, 2016 at 1:28:01 AM UTC+8, di...@veryhaha.com wrote: >> >> >> >> On Thursday, October 13, 2016 at 11:22:14 PM UTC+8, Chris Manghane wrote: >>> >>> In that example y is a nil interface value

Re: [go-nuts] don't understand the comment in spec Type assertions section

On Friday, October 14, 2016 at 1:28:01 AM UTC+8, di...@veryhaha.com wrote: > > > > On Thursday, October 13, 2016 at 11:22:14 PM UTC+8, Chris Manghane wrote: >> >> In that example y is a nil interface value of type l. The last line >> implies that for a type assertion to another interface type,

Re: [go-nuts] don't understand the comment in spec Type assertions section

On Thursday, October 13, 2016 at 11:22:14 PM UTC+8, Chris Manghane wrote: > > In that example y is a nil interface value of type l. The last line > implies that for a type assertion to another interface type, the operation > will only be possible if the underlying value implements both

Re: [go-nuts] Why "_ := x" is illegal but "var _ = x" is legal?

On Friday, October 14, 2016 at 12:49:43 AM UTC+8, Ian Lance Taylor wrote: > > On Thu, Oct 13, 2016 at 9:40 AM, > wrote: > > > > On Friday, October 14, 2016 at 12:14:34 AM UTC+8, Ian Lance Taylor > wrote: > >> > >> On Thu, Oct 13, 2016 at 8:36 AM,

Re: [go-nuts] Why "_ := x" is illegal but "var _ = x" is legal?

On Friday, October 14, 2016 at 12:14:34 AM UTC+8, Ian Lance Taylor wrote: > > On Thu, Oct 13, 2016 at 8:36 AM, > wrote: > > > > On Thursday, October 13, 2016 at 11:24:50 PM UTC+8, Jesper Louis > Andersen > > wrote: > >> > >> The rule is that a short variable

[go-nuts] Re: Are all bytes, alloced for any zero value of any type, zeros?

On Thursday, October 13, 2016 at 11:28:11 PM UTC+8, adon...@google.com wrote: > > Yes, the memory representation of the zero value of any type consists only > of zero bytes. > However, this is an implementation detail and not a consequence of the > spec. > Thanks for the explanation. --

Re: [go-nuts] don't understand the comment in spec Type assertions section

On Thursday, October 13, 2016 at 11:22:14 PM UTC+8, Chris Manghane wrote: > > In that example y is a nil interface value of type l. The last line > implies that for a type assertion to another interface type, the operation > will only be possible if the underlying value implements both

[go-nuts] Are all bytes, alloced for any zero value of any type, zeros?

. -- 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] About panic/recover in Golang

On Thursday, October 13, 2016 at 9:55:01 PM UTC+8, Konstantin Khomoutov wrote: > > On Thu, 13 Oct 2016 05:47:33 -0700 (PDT) > di...@veryhaha.com wrote: > > [...] > > Thanks, Ian. > > The recover1.go has many great examples to understand the mechanism > > of panic/recover. > > I think I

Re: [go-nuts] don't understand the comment in spec Type assertions section

On Thursday, October 13, 2016 at 8:52:14 PM UTC+8, Jan Mercl wrote: > > On Thu, Oct 13, 2016 at 2:42 PM wrote: > > > I don't understand the comment of the last line. Can someone explain it > for me? > > "r has type io.Reader" means that the type if expr.(T) is T. > > "and

Re: [go-nuts] About panic/recover in Golang

On Thursday, October 13, 2016 at 1:30:48 AM UTC+8, Ian Lance Taylor wrote: > > On Wed, Oct 12, 2016 at 9:21 AM, > wrote: > > I don't like the spec docs for panic/recover in Golang, for the spec > docs is > > vague and not clear on when recover will take effect. > > >

[go-nuts] don't understand the comment in spec Type assertions section

https://golang.org/ref/spec#Type_assertions var x interface{} = 7 // x has dynamic type int and value 7 i := x.(int) // i has type int and value 7 type I interface { m() } var y I s := y.(string)// illegal: string does not implement I (missing method m)

[go-nuts] Re: About panic/recover in Golang

On Thursday, October 13, 2016 at 12:31:35 AM UTC+8, di...@veryhaha.com wrote: > > I don't like the spec docs for panic/recover in Golang, for the spec docs > is vague and not clear on when recover will take effect. > > So I wrote some examples to get the mechanism of panic/recover in Golang. >

[go-nuts] About panic/recover in Golang

I don't like the spec docs for panic/recover in Golang, for the spec docs is vague and not clear on when recover will take effect. So I wrote some examples to get the mechanism of panic/recover in Golang. // example A func main() { defer func() {