Re: [go-nuts] Nil could be the zero value for type variables

[Will Faught]

Right, I discussed that:

Currently, if I understand correctly, the only way to do this is to declare
> a variable, and return that:
> var zeroValue V
> return zeroValue


On Mon, May 30, 2022 at 7:33 PM Bruno Albuquerque  wrote:

> This should work on your example:
>
> var zeroValue V
>
> On Mon, May 30, 2022, 6:39 PM Will Faught  wrote:
>
>> Hello, fellow Gophers!
>>
>> Currently, if I understand correctly, there's no expression for the zero
>> value for a type variable:
>>
>> type Map[K comparable, V any] struct {
>> ks []K
>> vs []V
>> }
>>
>> func (m Map[K, V]) Get(k K) V {
>> for i, k2 := range m.ks {
>> if k2 == k {
>> return m.vs[i]
>> }
>> }
>> return zeroValue // cannot currently express this
>> }
>>
>> This is a trivial example, but I've seen real questions about what to do
>> in these situations.
>>
>> Currently, if I understand correctly, the only way to do this is to
>> declare a variable, and return that:
>>
>> var zeroValue V
>> return zeroValue
>>
>> Why not allow nil to be used as the zero value for type variables, to
>> fill this gap?
>>
>> return nil // == V(nil)
>>
>> At runtime, nil would be the zero value for the specific type argument.
>>
>> Nil could actually be interpreted as the zero value for every type, even
>> outside of generics. The word "nil" means
>>  zero, anyway. This would be
>> handy in situations where you make a type a pointer just to avoid lots of
>> typing. For example:
>>
>> if condition1 {
>> return ReallyLongStructName{}, fmt.Errorf(...)
>> }
>> if condition2 {
>> return ReallyLongStructName{}, fmt.Errorf(...)
>> }
>>
>> Instead, you could keep the non-pointer type, and then do:
>>
>> if condition1 {
>> return nil, fmt.Errorf(...)
>> }
>> if condition2 {
>> return nil, fmt.Errorf(...)
>> }
>>
>> It would also solidify the type abstraction concept of generic functions,
>> where functions varying only in concrete types can be abstracted into one
>> generic function with type variables. For example:
>>
>> // Same implementations, different types
>>
>> func (m MapIntInt) Get(k int) int {
>> for i, k2 := range m.ks {
>> if k2 == k {
>> return m.vs[i]
>> }
>> }
>> return nil // nil, not 0, but means the same thing for int
>> }
>>
>> func (m MapStringString) Get(k string) string {
>> for i, k2 := range m.ks {
>> if k2 == k {
>> return m.vs[i]
>> }
>> }
>> return nil // nil, not "", but means the same thing for string
>> }
>>
>> // Same implementation, abstracted types
>>
>> func (m Map[K, V]) Get(k K) V {
>> for i, k2 := range m.ks {
>> if k2 == k {
>> return m.vs[i]
>> }
>> }
>> return nil // nil is 0 for int and "" for string
>> }
>>
>> Similar to how generics required an inversion of the meaning of
>> interfaces to be type sets, perhaps generics also requires an inversion of
>> the meaning of zero and nil values, where every type has a nil (default)
>> value, and for number-like types, that just so happens to be the number
>> zero, but for other types, it could be whatever makes sense for them.
>>
>> Anyway, I thought it was an interesting idea. Thanks for reading!
>>
>> --
>> 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/CAKbcuKjePVMPH1Fxv3tWAAm_msjAZKmtbJs2EMkQ7WGEgtAqyA%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKbcuKitNRH2NBSySY%2BReGzKDgyhapAW5D24XT-OvULDrcsB%3Dw%40mail.gmail.com.

Re: [go-nuts] Nil could be the zero value for type variables

[Bruno Albuquerque]

This should work on your example:

var zeroValue V

On Mon, May 30, 2022, 6:39 PM Will Faught  wrote:

> Hello, fellow Gophers!
>
> Currently, if I understand correctly, there's no expression for the zero
> value for a type variable:
>
> type Map[K comparable, V any] struct {
> ks []K
> vs []V
> }
>
> func (m Map[K, V]) Get(k K) V {
> for i, k2 := range m.ks {
> if k2 == k {
> return m.vs[i]
> }
> }
> return zeroValue // cannot currently express this
> }
>
> This is a trivial example, but I've seen real questions about what to do
> in these situations.
>
> Currently, if I understand correctly, the only way to do this is to
> declare a variable, and return that:
>
> var zeroValue V
> return zeroValue
>
> Why not allow nil to be used as the zero value for type variables, to fill
> this gap?
>
> return nil // == V(nil)
>
> At runtime, nil would be the zero value for the specific type argument.
>
> Nil could actually be interpreted as the zero value for every type, even
> outside of generics. The word "nil" means
>  zero, anyway. This would be
> handy in situations where you make a type a pointer just to avoid lots of
> typing. For example:
>
> if condition1 {
> return ReallyLongStructName{}, fmt.Errorf(...)
> }
> if condition2 {
> return ReallyLongStructName{}, fmt.Errorf(...)
> }
>
> Instead, you could keep the non-pointer type, and then do:
>
> if condition1 {
> return nil, fmt.Errorf(...)
> }
> if condition2 {
> return nil, fmt.Errorf(...)
> }
>
> It would also solidify the type abstraction concept of generic functions,
> where functions varying only in concrete types can be abstracted into one
> generic function with type variables. For example:
>
> // Same implementations, different types
>
> func (m MapIntInt) Get(k int) int {
> for i, k2 := range m.ks {
> if k2 == k {
> return m.vs[i]
> }
> }
> return nil // nil, not 0, but means the same thing for int
> }
>
> func (m MapStringString) Get(k string) string {
> for i, k2 := range m.ks {
> if k2 == k {
> return m.vs[i]
> }
> }
> return nil // nil, not "", but means the same thing for string
> }
>
> // Same implementation, abstracted types
>
> func (m Map[K, V]) Get(k K) V {
> for i, k2 := range m.ks {
> if k2 == k {
> return m.vs[i]
> }
> }
> return nil // nil is 0 for int and "" for string
> }
>
> Similar to how generics required an inversion of the meaning of interfaces
> to be type sets, perhaps generics also requires an inversion of the meaning
> of zero and nil values, where every type has a nil (default) value, and for
> number-like types, that just so happens to be the number zero, but for
> other types, it could be whatever makes sense for them.
>
> Anyway, I thought it was an interesting idea. Thanks for reading!
>
> --
> 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/CAKbcuKjePVMPH1Fxv3tWAAm_msjAZKmtbJs2EMkQ7WGEgtAqyA%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEd86TzRiQesDG%3Da-8Cjr084AdPGi0eTGV6yK%2BD4yr7gj17Kmw%40mail.gmail.com.

[go-nuts] Nil could be the zero value for type variables

[Will Faught]

Hello, fellow Gophers!

Currently, if I understand correctly, there's no expression for the zero
value for a type variable:

type Map[K comparable, V any] struct {
ks []K
vs []V
}

func (m Map[K, V]) Get(k K) V {
for i, k2 := range m.ks {
if k2 == k {
return m.vs[i]
}
}
return zeroValue // cannot currently express this
}

This is a trivial example, but I've seen real questions about what to do in
these situations.

Currently, if I understand correctly, the only way to do this is to declare
a variable, and return that:

var zeroValue V
return zeroValue

Why not allow nil to be used as the zero value for type variables, to fill
this gap?

return nil // == V(nil)

At runtime, nil would be the zero value for the specific type argument.

Nil could actually be interpreted as the zero value for every type, even
outside of generics. The word "nil" means
 zero, anyway. This would be handy
in situations where you make a type a pointer just to avoid lots of typing.
For example:

if condition1 {
return ReallyLongStructName{}, fmt.Errorf(...)
}
if condition2 {
return ReallyLongStructName{}, fmt.Errorf(...)
}

Instead, you could keep the non-pointer type, and then do:

if condition1 {
return nil, fmt.Errorf(...)
}
if condition2 {
return nil, fmt.Errorf(...)
}

It would also solidify the type abstraction concept of generic functions,
where functions varying only in concrete types can be abstracted into one
generic function with type variables. For example:

// Same implementations, different types

func (m MapIntInt) Get(k int) int {
for i, k2 := range m.ks {
if k2 == k {
return m.vs[i]
}
}
return nil // nil, not 0, but means the same thing for int
}

func (m MapStringString) Get(k string) string {
for i, k2 := range m.ks {
if k2 == k {
return m.vs[i]
}
}
return nil // nil, not "", but means the same thing for string
}

// Same implementation, abstracted types

func (m Map[K, V]) Get(k K) V {
for i, k2 := range m.ks {
if k2 == k {
return m.vs[i]
}
}
return nil // nil is 0 for int and "" for string
}

Similar to how generics required an inversion of the meaning of interfaces
to be type sets, perhaps generics also requires an inversion of the meaning
of zero and nil values, where every type has a nil (default) value, and for
number-like types, that just so happens to be the number zero, but for
other types, it could be whatever makes sense for them.

Anyway, I thought it was an interesting idea. Thanks for reading!

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

Re: [go-nuts] How to prevent default sorting of map

['Dan Kortschak' via golang-nuts]

On Mon, 2022-05-30 at 08:23 -0700, Vejju Deepesh wrote:
> I want know the method of preventing sorting by default and maintain
> the map in the order of insertion

If you want ordered return of elements and O(1) look-up, use a slice
and an index map. Insertion becomes and appends and a map insertion
with the length of the slice after append (if the element is not
already in the map - no-op otherwise), look-up is an index map query
and then slice access, and container dump is an iteration over the
slice.

-- 
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/0e521de4259d1f69a6d5126d7f01366211fa5a79.camel%40kortschak.io.

[go-nuts] Re: “Normal” vs. “error” (control flow) is a fundamental semantic distinction

[Harri L]

Thank you!

Indeed, the selected names follow the try/catch idiom, and with the err2 
, you can write code that includes 
non-local control flows. I hope that err2 is not confused with exception 
handling.

The Go2 try-proposal 

 
speaks about a helper library needed to get every help that try-macro could 
offer. The err2 package has that library now, and thanks to generics, the 
try-API is almost similar to try-macro.

I know many didn't like the try-proposal, but what has been a considerable 
surprise is how much benefit you get when merging panics and errors.

Rus Coxx: Error Handling -- Problem Overview 

:
"*Panics. We’ve spent a while trying to harmonize error handling and 
panics, so that cleanup due to error handling need not be repeated for 
cleanup due to panics. All our attempts at unifying the two only led to 
more complexity*." 

Then harmonization is now done with err2-package.

On Wednesday, May 25, 2022 at 2:15:18 PM UTC+3 yan.z...@gmail.com wrote:

> Try & Catch sounds great!
>
> 在2022年5月19日星期四 UTC+8 00:15:09 写道：
>
>> Hi all,
>>
>> I thought now was the time to go public. The automatic error propagation 
>> is possible with the help of a simple Go package, and it has been about 
>> three years now:
>>
>> func CopyFile(src, dst string) (err error) {
>> defer err2.Returnf(, "copy %s %s", src, dst)
>>
>> r := try.To1(os.Open(src))
>> defer r.Close()
>>
>> w := try.To1(os.Create(dst))
>> defer err2.Handle(, func() {
>> _ = os.Remove(dst)
>> })
>> defer w.Close()
>>
>> try.To1(io.Copy(w, r))
>> return nil
>> }
>>
>> The playground .
>>
>> A couple of blog posts about the subject:
>>
>>- Error Propagation 
>>
>> 
>>- Errors as Discriminated Unions 
>>
>>
>> I'm the author of those posts and the err2 package 
>> . Additional sources for original ideas 
>> are mentioned in the blogs and the package documentation. And, of course, 
>> pure error values are needed when transporting errors through channels.
>>
>> I hope that any gopher who tries the err2 package finds it as valuable 
>> and productive
>> as we have. Indeed, Go is one of the most pragmatic and refactor-friendly 
>> native languages.
>>
>> Best regards,
>> -Harri
>>
>

-- 
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/397750bd-9028-4165-9cbd-3a8406e42c94n%40googlegroups.com.

Re: [go-nuts] uber handler to collect stacktrace when program crashing

[Harri L]

If you write a wrapper, please look at the err2-package 
. It's an error-handling package, but we 
needed to build a panic-safe system with automatic stack tracing. Traces 
are context optimized as well. Here's a playground demo 
.

You add the following one-liners to your goroutines, and that's it.

go func() {
 *defer err2.CatchTrace(func(err error) {})*
 var b []byte
 b[1] = 0
}()

On Monday, May 30, 2022 at 6:11:47 PM UTC+3 sre.ag...@gmail.com wrote:

> Yes, I was asking about a generic handler.  
>
> I am thinking of writing a wrapper function which takes a function and 
> spuns up a goroutine with the above mentioned defer function by default.  
>
> On Sat, May 28, 2022 at 1:27 AM 'Sean Liao' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> I believe this is asking for a single handler that will apply to all 
>> goroutines, to which the answer is no such feature exists
>>
>> - sean
>>
>> On Sat, May 28, 2022, 03:09 Ian Lance Taylor  wrote:
>>
>>> On Fri, May 27, 2022 at 10:42 AM Aggarwal Sre  
>>> wrote:
>>> >
>>> > Is there a recommended pattern besides adding a defer call ( with 
>>> recover call, to collect debug stack trace) to each goroutine, for 
>>> collecting a stack trace when a golang is crashing due to any sort of panic.
>>> >
>>> > In other words, is there a way to register an uber handler ( probably 
>>> using OS signals) at the main function level, to indicate that a golang 
>>> program crashed and stacktrace to clearly specify where exactly?
>>>
>>> A panic handle is run at the bottom of the stack.  If you write this:
>>>
>>> defer func() {
>>> if recover() != nil {
>>> fmt.Printf("%s", debug.Stack())
>>> }
>>> }()
>>>
>>> in your main function, it will print a stack trace showing the point
>>> of the panic.
>>>
>>> Ian
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV4d9HxDbdp_in95j6aKFF_m%2BN_hFdeyUMuMOWRt5%2B6dw%40mail.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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAGabyPoRyv63ztmyrAGkuQ4u8Dcqffo4dUVo6H%3DczLU7%3DvsVcw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d7987acf-099b-4048-b38a-dcd01db0da47n%40googlegroups.com.

Re: [go-nuts] How to prevent default sorting of map

[Ian Lance Taylor]

On Mon, May 30, 2022 at 10:28 AM Vejju Deepesh  wrote:
>
> I want know the method of preventing sorting by default and maintain the map 
> in the order of insertion

The builtin map type does not support that.  Sorry.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVygYSrOeXTbbbYEA0hfSfs7_NAkofrPTNdF2tEUy%3DKVg%40mail.gmail.com.

[go-nuts] How to prevent default sorting of map

[Vejju Deepesh]

I want know the method of preventing sorting by default and maintain the 
map in the order of insertion

-- 
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/118b5b04-71cd-4d8d-896d-393c88708e17n%40googlegroups.com.

Re: [go-nuts] uber handler to collect stacktrace when program crashing

[Aggarwal Sre]

Yes, I was asking about a generic handler.

I am thinking of writing a wrapper function which takes a function and
spuns up a goroutine with the above mentioned defer function by default.

On Sat, May 28, 2022 at 1:27 AM 'Sean Liao' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I believe this is asking for a single handler that will apply to all
> goroutines, to which the answer is no such feature exists
>
> - sean
>
> On Sat, May 28, 2022, 03:09 Ian Lance Taylor  wrote:
>
>> On Fri, May 27, 2022 at 10:42 AM Aggarwal Sre 
>> wrote:
>> >
>> > Is there a recommended pattern besides adding a defer call ( with
>> recover call, to collect debug stack trace) to each goroutine, for
>> collecting a stack trace when a golang is crashing due to any sort of panic.
>> >
>> > In other words, is there a way to register an uber handler ( probably
>> using OS signals) at the main function level, to indicate that a golang
>> program crashed and stacktrace to clearly specify where exactly?
>>
>> A panic handle is run at the bottom of the stack.  If you write this:
>>
>> defer func() {
>> if recover() != nil {
>> fmt.Printf("%s", debug.Stack())
>> }
>> }()
>>
>> in your main function, it will print a stack trace showing the point
>> of the panic.
>>
>> Ian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV4d9HxDbdp_in95j6aKFF_m%2BN_hFdeyUMuMOWRt5%2B6dw%40mail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAGabyPoRyv63ztmyrAGkuQ4u8Dcqffo4dUVo6H%3DczLU7%3DvsVcw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABsnPPJYHvxDqO7RsX7vO%3Dt9B4ij-j-Nq_2LsfY4oX6cbZiz_Q%40mail.gmail.com.

[go-nuts] A cloud-native Go microservices framework with cli tool for productivity.

[Kevin Wan]

https://github.com/zeromicro/go-zero

go-zero (listed in CNCF Landscape: 
https://landscape.cncf.io/?selected=go-zero) is a web and RPC framework 
with lots of builtin engineering practices. It’s born to ensure the 
stability of the busy services with resilience design and has been serving 
sites with tens of millions of users for years.

-- 
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/0954ad9b-bd6e-456f-b032-587c01ef11e3n%40googlegroups.com.

[go-nuts] iup-go - Cross-platform UI library with native controls

[Milan Nikolic]

https://github.com/gen2brain/iup-go

These are Go bindings for IUP, an amazing C library designed to help you 
build NATIVE user interfaces in a cross-platform way.
It was developed at PUC-Rio, the same university as Lua, it started as a 
research project in the mid-90s, MIT licensed.
The project is alive and is maintained ever since. The API is very simple 
thanks to its attribute mechanism and the learning curve for a new user is 
often faster.

The C source code is included and compiled together with bindings, much 
better than if you include static libraries in the package, making it more 
portable.

These are just bindings for the core IUP library, other components like IM 
(image library) or CD (canvas drawing) are not included.
I just added an `ImageFromImage` function to load `image.Image`, we have 
image support in the standard library. And CD comes with many dependencies, 
macOS support doesn't exist, and it is complicated to include.
That means there is no support for additional controls (`matrix` and `cell` 
are important ones), but there is a chance (I guess) they can be rewritten 
to use only basic IUP drawing, which happened before with e.g. controls 
like colorbrowser, gauge, etc.

-- 
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/e19cb9fd-13da-4c99-a056-a2df2226f17an%40googlegroups.com.

[go-nuts] Fwd: Possible minor specification issues

[Jan Mercl]

Gentle ping after no feedback.

FTR: The proposed change was tested by an ad-hoc PEG interpreter based
on the updated EBNF:
https://gitlab.com/cznic/gc/-/blob/6cc7f3006a019a52c49db3d13276c0a5c6d24a00/v2/internal/ebnf/all_test.go#L275.

-- Forwarded message -
From: Jan Mercl <0xj...@gmail.com>
Date: Fri, May 20, 2022 at 9:42 PM
Subject: Possible minor specification issues
To: golang-nuts 
Cc: Robert Griesemer 


I think there might be two small omissions in the EBNF grammar for Go 1.18:

LiteralType = StructType | ArrayType | "[" "..." "]"
ElementType | SliceType | MapType | TypeName .
EmbeddedField = [ "*" ] TypeName .

It seems to me that in both productions s/TypeName/TypeName [ TypeArgs
]/ is correct. Other options are available, like changing the
definition of TypeName to include the optional TypeArgs part and
dropping the same from the Type production.

-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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VeVMOhESV%2BSeaEj5-D27B1DA3rdv3vxspXVP6x7UGjoQ%40mail.gmail.com.