from:"tapi...@gmail.com"



On Tuesday, February 27, 2024 at 3:42:25 PM UTC+8 Jan Mercl wrote:

On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com  
wrote: 

> From common sense, this is an obvious bug. But the spec is indeed not 
clear enough. 
> It doesn't state whether or not comparisons of pointers to two distinct 
zero-size variables should be consistent in a run session. 
> Though, from common sense, it should. 

"Pointers to distinct zero-size variables may or may not be equal." 

The outcome is specified to be not predictable. Expecting consistency 
means the outcome should be, or eventually become, predictable. That's 
the opposite of what the specs say. 


Then I would argue that the spec never guarantee (x != y) == ! (x == y).
for values of any types (including non-zero-size types). :D

-- 
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/4972f679-062b-4a4c-bf8e-31ab59d0147fn%40googlegroups.com.

[go-nuts] Re: Failed to compile a generic code using embedded struct

use 

   type Test[T, V interface{A; I}] struct{}

instead now. 

There are still several restrictions in custom generics: 
https://go101.org/generics/888-the-status-quo-of-go-custom-generics.html

On Monday, February 26, 2024 at 10:44:46 PM UTC+8 Albert Widiatmoko wrote:

> Hi Go community,
>
> I was playing with Go generics and writing some codes, but I faced some 
> problems. I want to ask questions and help from the community if possible. 
> Below, I am trying to build a generic struct via a method through another 
> generic struct.
>
> Here's the link to Go Playground: https://go.dev/play/p/Q0zOJUePkmR
>
> ---
>
> package main
>
> var _ I = (*A)(nil)
>
> type I interface {
> String() string
> }
>
> type A struct {
> str string
> }
>
> func (a A) String() string {
> return a.str
> }
>
> type AE[T, V I] struct {
> T1 T
> T2 V
> }
>
> // func (AE[T, V]) String() string {
> // return "test"
> // }
>
> type Test[T, V A] struct{}
>
> func (t Test[T, V]) S() AE[T, V] {
> return AE[T, V]{}
> }
>
> func main() {}
>
> ---
>
> I expected the program to run, but then I got an error:
>
> T does not satisfy I (missing method String)
>
> I a bit confused because A implements I interface. I think this must be 
> because I missed something with the Go generics.
>
> Thank you.
>
>

-- 
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/e3288ddb-e86f-4886-b5da-c66a4617ecebn%40googlegroups.com.

Re: [go-nuts] Equality of interface of an empty struct - why?



On Tuesday, February 27, 2024 at 2:25:46 AM UTC+8 Brien Colwell wrote:

Interesting. That seems to break the comparable spec.

>> Pointer types are comparable. Two pointer values are equal if they point 
to the same variable or if both have value nil. Pointers to distinct 
zero-size variables may or may not be equal.


>From common sense, this is an obvious bug. But the spec is indeed not clear 
enough.
It doesn't state whether or not comparisons of pointers to two distinct 
zero-size variables should be consistent in a run session.
Though, from common sense, it should.
 


>> it would be valid for `==` on pointers to zero-sized types to always 
evaluate to `true`,

This would be more straightforward behavior.



On Feb 26, 2024, at 9:24 AM, tapi...@gmail.com  wrote:

package main

var a, b [0]int
var p, q = , 

func main() {
if (p == q) {
p, q = , 
println(p == q) // false
}
}

On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote:

I'm confused by this output. It appears that the interface of two different 
pointers to an empty struct are equal. In all other cases, interface 
equality seems to be the pointer equality. What's going on in the empty 
struct case?

```
package main

import "fmt"

type Foo struct {
}

func (self *Foo) Hello() {
}

type FooWithValue struct {
A int
}

func (self *FooWithValue) Hello() {
}

type Bar interface {
Hello()
}

func main() {
a := {}
b := {}
fmt.Printf("%t\n", *a == *b)
fmt.Printf("%t\n", a == b)
fmt.Printf("%t\n", Bar(a) == Bar(b))

c := {A: 1}
d := {A: 1}
fmt.Printf("%t\n", *c == *d)
fmt.Printf("%t\n", c == d)
fmt.Printf("%t\n", Bar(c) == Bar(d))
}
```

Prints (emphasis added on the strange case):

```
true
false
**true**
true
false
false
```



-- 
You received this message because you are subscribed to a topic in the 
Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/golang-nuts/JBVqWYFdtC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
golang-nuts...@googlegroups.com.

To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6fc9b600-6707-414c-b19b-e5e14919c5a5n%40googlegroups.com
 
<https://groups.google.com/d/msgid/golang-nuts/6fc9b600-6707-414c-b19b-e5e14919c5a5n%40googlegroups.com?utm_medium=email_source=footer>
.


-- 
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/bf153de9-91fd-47e3-8aa3-b738a5b55109n%40googlegroups.com.

[go-nuts] Re: Equality of interface of an empty struct - why?

package main

var a, b [0]int
var p, q = , 

func main() {
if (p == q) {
p, q = , 
println(p == q) // false
}
}

On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote:

> I'm confused by this output. It appears that the interface of two 
> different pointers to an empty struct are equal. In all other cases, 
> interface equality seems to be the pointer equality. What's going on in the 
> empty struct case?
>
> ```
> package main
>
> import "fmt"
>
> type Foo struct {
> }
>
> func (self *Foo) Hello() {
> }
>
> type FooWithValue struct {
> A int
> }
>
> func (self *FooWithValue) Hello() {
> }
>
> type Bar interface {
> Hello()
> }
>
> func main() {
> a := {}
> b := {}
> fmt.Printf("%t\n", *a == *b)
> fmt.Printf("%t\n", a == b)
> fmt.Printf("%t\n", Bar(a) == Bar(b))
>
> c := {A: 1}
> d := {A: 1}
> fmt.Printf("%t\n", *c == *d)
> fmt.Printf("%t\n", c == d)
> fmt.Printf("%t\n", Bar(c) == Bar(d))
> }
> ```
>
> Prints (emphasis added on the strange case):
>
> ```
> true
> false
> **true**
> true
> false
> false
> ```
>
>
>

-- 
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/6fc9b600-6707-414c-b19b-e5e14919c5a5n%40googlegroups.com.

[go-nuts] Re: Equality of interface of an empty struct - why?

2024-02-25 Thread tapi...@gmail.com

The behavior of Go 1.9 or 1.10 is even more weird.
They make the following code print false. ;D

package main

type T struct {}

func main() {
  var a, b = {}, {}
  println(a == b || a != b)
}


On Sunday, February 25, 2024 at 4:30:22 PM UTC+8 tapi...@gmail.com wrote:

> Absolutely a bug.
>
> On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote:
>
>> I'm confused by this output. It appears that the interface of two 
>> different pointers to an empty struct are equal. In all other cases, 
>> interface equality seems to be the pointer equality. What's going on in the 
>> empty struct case?
>>
>> ```
>> package main
>>
>> import "fmt"
>>
>> type Foo struct {
>> }
>>
>> func (self *Foo) Hello() {
>> }
>>
>> type FooWithValue struct {
>> A int
>> }
>>
>> func (self *FooWithValue) Hello() {
>> }
>>
>> type Bar interface {
>> Hello()
>> }
>>
>> func main() {
>> a := {}
>> b := {}
>> fmt.Printf("%t\n", *a == *b)
>> fmt.Printf("%t\n", a == b)
>> fmt.Printf("%t\n", Bar(a) == Bar(b))
>>
>> c := {A: 1}
>> d := {A: 1}
>> fmt.Printf("%t\n", *c == *d)
>> fmt.Printf("%t\n", c == d)
>> fmt.Printf("%t\n", Bar(c) == Bar(d))
>> }
>> ```
>>
>> Prints (emphasis added on the strange case):
>>
>> ```
>> true
>> false
>> **true**
>> true
>> false
>> false
>> ```
>>
>>
>>

-- 
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/e4429119-5c91-44d1-93c4-dc877efdd7b9n%40googlegroups.com.

[go-nuts] Re: Equality of interface of an empty struct - why?

2024-02-25 Thread tapi...@gmail.com

Absolutely a bug.

On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote:

> I'm confused by this output. It appears that the interface of two 
> different pointers to an empty struct are equal. In all other cases, 
> interface equality seems to be the pointer equality. What's going on in the 
> empty struct case?
>
> ```
> package main
>
> import "fmt"
>
> type Foo struct {
> }
>
> func (self *Foo) Hello() {
> }
>
> type FooWithValue struct {
> A int
> }
>
> func (self *FooWithValue) Hello() {
> }
>
> type Bar interface {
> Hello()
> }
>
> func main() {
> a := {}
> b := {}
> fmt.Printf("%t\n", *a == *b)
> fmt.Printf("%t\n", a == b)
> fmt.Printf("%t\n", Bar(a) == Bar(b))
>
> c := {A: 1}
> d := {A: 1}
> fmt.Printf("%t\n", *c == *d)
> fmt.Printf("%t\n", c == d)
> fmt.Printf("%t\n", Bar(c) == Bar(d))
> }
> ```
>
> Prints (emphasis added on the strange case):
>
> ```
> true
> false
> **true**
> true
> false
> false
> ```
>
>
>

-- 
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/69182541-008d-46c6-b75c-0c8472026e32n%40googlegroups.com.

[go-nuts] Re: It seems that go 1.22 has optimized the implementation of string to byte slicing and no longer requires memory allocation.

2023-11-27 Thread tapi...@gmail.com

See https://github.com/golang/go/issues/2205
The tip compiler is able to detect some simple string->[]byte cases in 
which duplication is not needed.

On Monday, November 27, 2023 at 8:12:54 PM UTC+8 fliter wrote:

> It seems that go 1.22 has optimized the implementation of string to byte 
> slicing and no longer requires memory allocation.
>
>
> But why not optimize byte slicing to string conversion together?
>
>
> ```go
> package main
>
> import (
> "reflect"
> "testing"
> "unsafe"
> )
>
>
> func BenchmarkString(b *testing.B) {
> byteSli := []byte{123, 34, 100, 101, 102, 97, 117, 108, 116, 34, 58, 123, 
> 34, 99, 111, 109, 109, 111, 110, 34, 58, 123, 34, 112, 101, 116, 34, 58, 
> 123, 34, 102, 105, 118, 101, 34, 58, 34, 230, 150, 145, 230, 150, 145, 34, 
> 44, 34, 102, 111, 117, 114, 34, 58, 34, 231, 154, 174, 231, 147, 156, 231, 
> 147, 156, 34, 44, 34, 111, 110, 101, 34, 58, 34, 229, 188, 165, 229, 188, 
> 165, 230, 135, 181, 34, 44, 34, 116, 104, 114, 101, 101, 34, 58, 34, 229, 
> 145, 134, 229, 145, 134, 34, 44, 34, 116, 119, 111, 34, 58, 34, 233, 187, 
> 132, 230, 169, 153, 230, 169, 153, 34, 125, 44, 34, 114, 101, 108, 97, 116, 
> 105, 111, 110, 34, 58, 123, 34, 102, 97, 116, 104, 101, 114, 34, 58, 34, 
> 99, 117, 105, 120, 120, 120, 120, 120, 120, 120, 34, 44, 34, 109, 111, 116, 
> 104, 101, 114, 34, 58, 34, 121, 105, 110, 120, 120, 120, 120, 120, 34, 44, 
> 34, 119, 105, 102, 101, 34, 58, 34, 112, 101, 110, 103, 120, 120, 34, 125, 
> 125, 125, 125}
>
> _ = string(byteSli)
>
> }
>
> func BenchmarkUnsafe(b *testing.B) {
> byteSli := []byte{123, 34, 100, 101, 102, 97, 117, 108, 116, 34, 58, 123, 
> 34, 99, 111, 109, 109, 111, 110, 34, 58, 123, 34, 112, 101, 116, 34, 58, 
> 123, 34, 102, 105, 118, 101, 34, 58, 34, 230, 150, 145, 230, 150, 145, 34, 
> 44, 34, 102, 111, 117, 114, 34, 58, 34, 231, 154, 174, 231, 147, 156, 231, 
> 147, 156, 34, 44, 34, 111, 110, 101, 34, 58, 34, 229, 188, 165, 229, 188, 
> 165, 230, 135, 181, 34, 44, 34, 116, 104, 114, 101, 101, 34, 58, 34, 229, 
> 145, 134, 229, 145, 134, 34, 44, 34, 116, 119, 111, 34, 58, 34, 233, 187, 
> 132, 230, 169, 153, 230, 169, 153, 34, 125, 44, 34, 114, 101, 108, 97, 116, 
> 105, 111, 110, 34, 58, 123, 34, 102, 97, 116, 104, 101, 114, 34, 58, 34, 
> 99, 117, 105, 120, 120, 120, 120, 120, 120, 120, 34, 44, 34, 109, 111, 116, 
> 104, 101, 114, 34, 58, 34, 121, 105, 110, 120, 120, 120, 120, 120, 34, 44, 
> 34, 119, 105, 102, 101, 34, 58, 34, 112, 101, 110, 103, 120, 120, 34, 125, 
> 125, 125, 125}
>
> _ = *(*string)(unsafe.Pointer())
> }
>
> func BenchmarkByteStyle(b *testing.B) {
>
> str := 
> `{"default":{"common":{"pet":{"five":"aa","four":"bb","one":"cc","three":"dd","two":"黄ee"},"relation":{"father":"ff","mother":"mm","wife":"ww"`
>
> _ = []byte(str)
>
> }
>
> func BenchmarkWithUnsafe(b *testing.B) {
>
> str 
> := 
> `{"default":{"common":{"pet":{"five":"aa","four":"bb","one":"cc","three":"dd","two":"黄ee"},"relation":{"father":"ff","mother":"mm","wife":"ww"`
>
> sh := (*reflect.StringHeader)(unsafe.Pointer())
> bh := reflect.SliceHeader{
> Data: sh.Data,
> Len:  sh.Len,
> Cap:  sh.Len,
> }
> _ = *(*[]byte)(unsafe.Pointer())
>
> }
> ```
>
> ```bench_test.go
> package main
>
> import (
> "testing"
> )
>
>
> func BenchmarkTest1(b *testing.B) {
> for i := 0; i < b.N; i++ {
> BenchmarkString(b)
> }
> }
>
> func BenchmarkTest2(b *testing.B) {
> for i := 0; i < b.N; i++ {
> BenchmarkUnsafe(b)
> }
> }
>
> func BenchmarkTest3(b *testing.B) {
> for i := 0; i < b.N; i++ {
> BenchmarkByteStyle(b)
> }
> }
>
> func BenchmarkTest4(b *testing.B) {
> for i := 0; i < b.N; i++ {
> BenchmarkWithUnsafe(b)
> }
> }
> ```
>
> when go version is 1.21
>
> ```shell
>  go version
> go version go1.21.0 darwin/arm64
>
> goos: darwin
> goarch: arm64
> pkg: bc
> BenchmarkTest1-83707800832.45 ns/op  192 
> B/op  1 allocs/op
> BenchmarkTest2-81441068409.181 ns/op   0 
> B/op  0 allocs/op
> BenchmarkTest3-83897337528.94 ns/op  192 
> B/op  1 allocs/op
> BenchmarkTest4-810   0.3130 ns/op  0 
> B/op  0 allocs/op
> PASS
> ok  bc  6.038s
>
> ```
>
>
>
> when go version is 1.22
>
> ```shell
>  go version
> go version devel go1.22-631a6c2abf Fri Nov 17 23:34:11 2023 + 
> darwin/arm64
>
>
>  go test -test.bench=".*" -benchmem
> goos: darwin
> goarch: arm64
> pkg: bc
> BenchmarkTest1-83572733433.51 ns/op  192 
> B/op  1 allocs/op
> BenchmarkTest2-81471724258.157 ns/op   0 
> B/op  0 allocs/op
> BenchmarkTest3-810   0.3136 ns/op  0 
> B/op  0 allocs/op
> BenchmarkTest4-810   0.3153 ns/op  0 
> B/op  0 allocs/op
> PASS
> ok  bc  5.095s
> ```
>
>
>
>

-- 
You received this message because you are subscribed to

Re: [go-nuts] Generic type for struct method: constraint problem && cannot use (untyped string constant) as string value

2023-11-09 Thread tapi...@gmail.com

The uint8 in cachedFn[uint8, V] is the type parameter name, it can be 
arbitrary valid identifier.
It shadows the predeclared uint8 identifier.

On Friday, November 10, 2023 at 12:25:05 PM UTC+8 ahuigo wrote:

> Btw, please ignore the type logic in my code, I wrote this piece of code 
> just to illustrate the oddities of generics in struct methods.
> Regardless of whether its type is int, string, any, *or the exact uint8, 
> this error is very strange.*
>
>
> // it doesn't work
> func (c *cachedFn[uint8, V]) Get0() (V, error) {
> var s uint8 = 0
> s = 0 // error: cannot use 0 (untyped int constant) as uint8 value in 
> assignment
> fmt.Printf("cache key: %#v, %T\n", s, s) // cache key: 0, uint8
> return c.Get(s)
> }
>
> // it works
> func (c *cachedFn[uint8, V]) Get0() (V, error) {
> var s uint8 = 0
> fmt.Printf("cache key: %#v, %T\n", s, s) // cache key: 0, uint8
> return c.Get(s)
> }
> On Friday, November 10, 2023 at 4:34:46 AM UTC+8 Axel Wagner wrote:
>
>> Yes, this has come up before.
>>
>> On Fri, Nov 10, 2023 at 7:09 AM ahuigo  wrote:
>>
>>> There is an example: https://go.dev/play/p/guzOWRKi-yp
>>>
>>> ```
>>> func (c *cachedFn[string, V]) Get0() (V, error) {
>>> // var s any
>>> var s string
>>> s = "abc" // error: cannot use "abc" (untyped string constant) as string 
>>> value in assignment
>>> fmt.Printf("cache key: %#v, %T\n", s, s) // cache key: 0, uint8
>>> return c.Get(s)
>>> }
>>> ```
>>> I find the generic type of the struct method a bit confusing.
>>> 1.  The type `cachedFn[string, V]` does not really constrain the type 
>>> of  `s` to **string**. It's actual type is `uint8`
>>>
>>
>> The type `cachedVn[string, V]` *would* in fact instantiate `cachedVn` 
>> with `string` and `V`.
>> But that's not what you are doing. You are writing the receiver type as 
>> `fun c(c *cachedFn[string, V])`, which means that "the receiver is the 
>> generic type `cachedVn` with two type parameters called `string` and `V`".
>> Predeclared identifiers in Go are not special in any way, you can re-use 
>> them for your own variables and types - or type parameters. So what you are 
>> doing here is fundamentally similar to this problem: 
>> https://go.dev/play/p/lDE-o7fGHi8
>>
>> There probably should be a vet check for using a predeclared identifier 
>> as a type parameter name (or maybe even for any re-use of a predeclared 
>> identifier).
>>
>> 2. And this error is a bit strange. (`s = "abc"  // error: cannot use 
>>> "abc" (untyped string constant) as string value in assignment. ` )
>>>
>>>
>>> -- 
>>> 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/58c92577-cb98-401a-978d-c22a1fb493ccn%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/3b7f2865-f225-4e5e-ae0e-7edf5bb333d6n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

2023-10-24 Thread tapi...@gmail.com

My another surprise is that the below partial instantiation doesn't work. 

s = slices.Insert[[]Suiter](s, len(s), Clubs{}) // not work
s = slices.Insert[[]Suiter, Suiter](s, len(s), Clubs{}) // works

On Monday, October 23, 2023 at 11:01:47 AM UTC+8 tapi...@gmail.com wrote:

> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>
> Sorry, I didn't look your full code.
> I think the full code should work with Go toolchain 1.21.n.
>
>
> Aha, it actually doesn't. I'm surprised.
>
>
> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>
> How so? 
>
> Can you give an example scenario where it could cause unintended 
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>

-- 
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/7bd4727b-46ec-4972-b9a3-f7271892bff5n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

2023-10-24 Thread tapi...@gmail.com

In the "Special situations" section of this article 
https://go.dev/blog/type-inference,
it is mentioned a bit on this.
My understanding of that chapter is, when choosing the inferred type 
argument,
the current priority is: name types > directional channel types > other 
unnamed types.

In the case of the current thread, there are two type argument candidates, 
both of
them are named types, so the type interference fails.

Maybe the priority should be: interface types > named types > directional 
channel types > other unnamed types.

On Tuesday, October 24, 2023 at 3:53:14 AM UTC+8 Mike Schinkel wrote:

> Yes, I was surprised too.  It actually took me the better part of a day 
> trying to get this to work before finally posting to the list.
>
> It turns out that this limit was actually documented by Ian Lance Taylor 
> back in February 2023:
>
> https://github.com/golang/go/issues/58650
>
> Look for the section entitled *"Inferring based on interfaces."*
>
> Again, it sure would be nice it this were possible, if for no other reason 
> than to keep others being as time-inefficient as I was while trying to 
> figure it out. 
>
> -Mike
> On Sunday, October 22, 2023 at 11:01:47 PM UTC-4 tapi...@gmail.com wrote:
>
>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>>
>> Sorry, I didn't look your full code.
>> I think the full code should work with Go toolchain 1.21.n.
>>
>>
>> Aha, it actually doesn't. I'm surprised.
>>
>>
>> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>>
>> How so? 
>>
>> Can you give an example scenario where it could cause unintended 
>> consequences?  Or some other negative?
>>
>> -Mike
>>
>> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
>> wrote:
>>
>>
>> It is hard to call such type inference better. That is too aggressive.
>>
>>

-- 
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/ee59d818-9219-44b3-9841-51e67037a02dn%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

2023-10-22 Thread tapi...@gmail.com



On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:

Sorry, I didn't look your full code.
I think the full code should work with Go toolchain 1.21.n.


Aha, it actually doesn't. I'm surprised.


On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:

How so? 

Can you give an example scenario where it could cause unintended 
consequences?  Or some other negative?

-Mike

On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com wrote:


It is hard to call such type inference better. That is too aggressive.

-- 
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/81b551a2-f8b5-45b7-88fa-b6207f7a324an%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

2023-10-22 Thread tapi...@gmail.com

Sorry, I didn't look your full code.
I think the full code should work with Go toolchain 1.21.n.

On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:

> How so? 
>
> Can you give an example scenario where it could cause unintended 
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>

-- 
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/9353cb40-bda5-439f-a1a9-6b78aa7936f8n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

2023-10-21 Thread tapi...@gmail.com

On Sunday, October 22, 2023 at 4:09:51 AM UTC+8 Mike Schinkel wrote:

@Axel Wagner — 

Thank you for adding clarity to this.

Yes, it would be nice if we could get this to be handled with better type 
inference. 

It is hard to call such type inference better. That is too aggressive.

But unless and until then, we have our workarounds.

On Saturday, October 21, 2023 at 4:01:05 PM UTC-4 Axel Wagner wrote:

This is purely a type-inference problem. If you explicitly instantiate 
`Append`, it works: https://goplay.tools/snippet/15RFAPFPl3y
Type inference is still relatively limited. It might become possible to at 
some point omit the instantiation. I think this might be "Inferring based 
on interfaces" in https://github.com/golang/go/issues/58650
Until then, it's expected that there will be some cases where you need to 
specify the types.

On Sat, Oct 21, 2023 at 9:45 PM Mike Schinkel  wrote:

No, that pre-generics case is not sufficient for my use-case.  

For my use-case I need to be able to use other types besides []Suiter such 
as []int, e.g.:

var n []int
n = Append(n, 1)
n = Append(n, 2)
n = Append(n, 3)
n = Append(n, 4)
for _, i := range n {
fmt.Printf("Int: %d\n", i)
}

See full code in playground .
On Saturday, October 21, 2023 at 3:15:03 PM UTC-4 Dan Kortschak wrote:

On Sat, 2023-10-21 at 11:58 -0700, Mike Schinkel wrote: 
> Recently I was trying to write a func using generics where I wanted 
> to use a slice of an interface that would contain implementers of 
> that interface and then pass those types to a generic function, but I 
> ran into this error: 
> 
> type MyStruct of MySlice{} does not match inferred type MyInterface 
> for T 
> 
> My code is complex so I wrote the simplest example for this email and 
> here is part of that code: 
> 
> type Suiter interface { 
> Suit() 
> } 
> func Append[T any](s []T, i T) []T { 
> return append(s, i) 
> } 
> func main() { 
> var s []Suiter 
> 
> //CAN GENERICS SUPPORT THIS? 
> //s = Append(s, Clubs{}) 
> //s = Append(s, Hearts{}) 
> //s = Append(s, Diamonds{}) 
> //s = Append(s, Spades{}) 
> 
> //VERSUS HAVING TO DO THIS? 
> s = Append(s, Suiter(Clubs{})) 
> s = Append(s, Suiter(Hearts{})) 
> s = Append(s, Suiter(Diamonds{})) 
> s = Append(s, Suiter(Spades{})) 
> 
> for _, suit := range s { 
> fmt.Printf("Suit: %s\n", suitName(suit)) 
> } 
> } 
> The full code is here in a playground. 
> 
> Note: My example func Append() makes no sense in real use, I only use 
> it as it should be an easily understood example to show the syntax I 
> am trying to illustrate. 
> 
> Question: Is there a way to write Append() such that I can call 
> Append(s, Clubs{}) instead of having to write Append(s, 
> Suiter(Clubs{}))? 
> 
> And if no, is there a chance that in the future Go generics will be 
> able to support that level of type inference? 
> 

The pre-generics language handles this case: 
https://go.dev/play/p/jaJF7LTSVYe 

Is there something about your real case that makes this not acceptable? 

-- 
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/805dbd4a-e2a0-426e-b61f-45b9333803f5n%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/3225354d-de49-4f77-b719-2e4665f7963fn%40googlegroups.com.

Re: [go-nuts] Possible Go Compiler or Runtime bug?

2023-07-27 Thread tapi...@gmail.com

On Friday, July 28, 2023 at 6:44:21 AM UTC+8 wagner riffel wrote:

On 27/07/2023 03:48, Kyle Harrity wrote:
> Maybe this is a known issue and or expected behavior so I thought I'd
> ask here before raising an issue on github.
>
I think I know what's going on, the compiler inlined getStrBytes and can
prove "k" is short enough to put in the stack, then the runtime creates
the slice backed from an array on the stack, but never sets its
capacity, just length, so you're left with 32 bytes of capacity to
expand (see
https://go.googlesource.com/go/+/refs/tags/go1.20.6/src/runtime/string.go#170).

When you uncomment your print of k, then the compiler can't prove that
fmt.Printf won't keep the address of k, so it's not safe to store it on
the stack anymore, and you have the "expected behavior", an array
allocated from rawbyteslice which does set the capacity to len(s) (0 in
this case).

Note that even if it is not stored on the stack, the behavior is still not
always "expected".
When it is stored on heap. the capacity will be aligned to a nearby memory
class size
(even this is also implementation specific).

In the linked code above, changing "b = buf[:len(s):len(s)]" should
"fix" this, it's quoted because I did grasp through the spec and
couldn't find anything about which is the capacity of a slice created
from a conversion of a string, as far as I can tell both programs are
valid.

--
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/bcb56d33-f24f-4baa-87da-db156d10ab67n%40googlegroups.com.

[go-nuts] Re: Short Variable Declarations Are Oversold

2023-04-23 Thread tapi...@gmail.com


Type inference is not the main purpose (or even the purpose) of short 
declarations.
I do agree that the negative impact of short declarations is larger than 
its positive impact,
for reasons different from the one you described. Some reasons:
* short declarations causes confusions (esp, for new gophers) at some 
situations.
* short declarations overlap too much functionalities with normal 
declarations.
* short declarations indeed hurt readabilities at some situations (but not 
the ones as you described).

On Sunday, April 23, 2023 at 6:31:11 AM UTC+8 jlfo...@berkeley.edu wrote:

> As a beginning Go programmer, I was initially attracted to the short 
> variable declaration syntax.
>
> It’s great for declaring variables of a simple type. What could be wrong 
> with letting the Go compiler infer a variable type by looking at what’s 
> being assigned to the variable, such as:
>
> func main() {
>
> x := 10
>
> }
>
> Nothing. This is trivially the same as
>
> func main() {
>
> var x int
>
> x = 10
>
> }
>
> I didn’t have to waste my precious time by entering an explicit type 
> declaration for “x” when the compiler already knew what it was.
>
> But what about something like
>
> import “os”
>
> func main() {
>
>  file, _ := os.Open(os.Args[1])
>
> }
>
> Again, nothing is wrong, at least not until I have to pass “file” to 
> another function. For example
>
> import “os”
>
> func main() {
>
>  file, _ := os.Open(os.Args[1])
>
> myfunc(file)
>
> }
>
> func myfunc(file ???) {
>
> }
>
> What type should I use to declare “file” in the parameter list for 
> myfunc()? As a new Go programmer I have to admit that I haven’t memorized 
> all the types used in the Go standard library. So, I have to break off 
> working on myfunc() to look up the type returned by os.Open(). This isn’t a 
> huge deal, but it’s a distraction and can waste time. I suppose that as I 
> gain experience with Go, I’ll have to do this less and less.
>
> But, it doesn’t matter how experienced I am with Go when I start using 
> user-defined types from packages that aren’t in the Go standard library. 
> For example (from Ben Hoyt’s excellent goawk program):
>
> import "github.com/benhoyt/goawk/parser"
>
> func main() {
>
> prog, err := parser.ParseProgram(fileReader.Source(), parserConfig)
>
> myfunc(prog)
>
> }
>
> func myfunc(prog ???) {
>
> }
>
> Since I’m going to have to look up the returned types of 
> parse.ParseProgram anyway, what’s the advantage of using a short variable 
> declaration? They just delay the inevitable.
>
> Short definitions detract from one of Go’s primary goals - readability. I 
> started using Go in the first place because I wanted a strongly typed 
> language with explicit type declarations. 
>
> As a result of all this, I’ve started to avoid short variable 
> declarations, except when I’m initializing a variable inside an "if" 
> , "for" 
> , or "switch 
> ” statement, such as
>
> if v := math.Pow(x, n); v < lim {
>
> }
>
> for i := 0; i < 10; i++ {
>
> }
>
> switch os := runtime.GOOS; os {
>
> }
>
> In these cases I have no choice if I want to declare local temporary 
> variables since long declarations aren’t syntactically allowed.
>
> I doubt if this note will change anybody’s mind but it’s something to 
> think about.
>

-- 
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/8c5aeb04-bcd7-45c3-94a1-d128f9cb0834n%40googlegroups.com.

[go-nuts] Re: Redfining loop variable semantics - what's the plan?

2023-04-11 Thread tapi...@gmail.com

Not to mention that the change for "for;;" is so counter-intuitive and 
violates the try-to-be-explicit principle in Go.

On Wednesday, April 12, 2023 at 9:08:24 AM UTC+8 tapi...@gmail.com wrote:

> The plan for “for;;” is much more risky than “for-each”, because “for;;” 
> has more variation uses in reality.
> I have no doubt that many non-bug compatibility-broken or 
> performance-degradation cases will be found in the GOEXPERIMENT phase.
>
> On Saturday, March 25, 2023 at 2:44:59 PM UTC+8 Amnon wrote:
>
>> Hi Gophers,
>> Last year there was a discussion about removing one of the 
>> more common gotchas in Go.
>>
>> To quote from the discussion:
>>
>> the problem is that loops like this one don’t do what they look like they 
>> do:
>>
>> var all []*Item
>> for _, item := range items { all = append(all, ) } 
>>
>> That is, this code has a bug. After this loop executes, all contains 
>> len(items) identical pointers, each pointing at the same Item, holding 
>> the last value iterated over. This happens because the item variable is 
>> per-loop, not per-iteration:  is the same on every iteration, and 
>> item is overwritten on each iteration. 
>> https://github.com/golang/go/discussions/56010
>>
>> What was the resolution of this discussion?
>> Was the proposed change accepted?
>> Will it be released in Go 1.21 or 1.22?
>>
>> It is hard to figure this out from the discussion. There are hundreds of 
>> comments,
>> but there is no clear marking of the resolution (apart from the 
>> discussion now being closed) either at the top of bottom of the discussion.
>>
>>
>>

-- 
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/faa17ec8-ba56-4e19-b50d-ec2cc829a5bfn%40googlegroups.com.

[go-nuts] Re: Redfining loop variable semantics - what's the plan?

2023-04-11 Thread tapi...@gmail.com

The plan for “for;;” is much more risky than “for-each”, because “for;;” 
has more variation uses in reality.
I have no doubt that many non-bug compatibility-broken or 
performance-degradation cases will be found in the GOEXPERIMENT phase.

On Saturday, March 25, 2023 at 2:44:59 PM UTC+8 Amnon wrote:

> Hi Gophers,
> Last year there was a discussion about removing one of the 
> more common gotchas in Go.
>
> To quote from the discussion:
>
> the problem is that loops like this one don’t do what they look like they 
> do:
>
> var all []*Item
> for _, item := range items { all = append(all, ) } 
>
> That is, this code has a bug. After this loop executes, all contains 
> len(items) identical pointers, each pointing at the same Item, holding 
> the last value iterated over. This happens because the item variable is 
> per-loop, not per-iteration:  is the same on every iteration, and 
> item is overwritten on each iteration. 
> https://github.com/golang/go/discussions/56010
>
> What was the resolution of this discussion?
> Was the proposed change accepted?
> Will it be released in Go 1.21 or 1.22?
>
> It is hard to figure this out from the discussion. There are hundreds of 
> comments,
> but there is no clear marking of the resolution (apart from the discussion 
> now being closed) either at the top of bottom of the discussion.
>
>
>

-- 
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/86379ce9-a958-4b57-a834-e789d1e03495n%40googlegroups.com.

Re: [go-nuts] Create a 1GB ballast but it takes up RSS and pages are Dirty?

2022-11-06 Thread tapi...@gmail.com

I ever also found this problem: global ballast doesn't work.
So I always use local ballast instead now.

On Sunday, November 6, 2022 at 8:37:55 PM UTC+8 hit.zh...@gmail.com wrote:

> Before, I think the memory is allocated by mmap anon, which Linux OS 
> guarantees reading will return zero value and no physical pages allocated. 
> When writing happens, the physical pages will be allocated. Then I think 
> the create a byte slice maybe the same.
>
> Your idea is clear. I agree with it. 
>
> Just now, I use gdb to dump the ballast anon memory and use hexdump to 
> check its dirty content, all data is zero (Maybe zeroing happens).
> But after turning GC off, it works as expected (no RSS is taken, no 
> DIRTY). 
> I think there must be something I didn't get it.
>
> On Sunday, November 6, 2022 at 8:11:51 PM UTC+8 Jan Mercl wrote:
>
>> On Sun, Nov 6, 2022 at 12:54 PM Kn (Kn)  wrote: 
>>
>> > Now the problem begins. I expect the ballast like `ballast := 
>> make([]byte, 1<<30)` shouldn't take up any physical memory because there's 
>> no any writing to it. 
>>
>> The backing array is specified to be zeroed, so we cannot say there's 
>> no writing to it. Depending on the size of the backing array and the 
>> operating system it may not get written as an optimization if backed 
>> by memory the OS can guarantee to be zero filled. Only then it may 
>> remain not yet bound to physical memory. 
>>
>> A simple implementation will just zero it, meaning the opposite 
>> happens - every byte of the backing array gets written and backing 
>> pages for it get allocated. 
>>
>

-- 
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/68ef4bf7-3463-4e14-9e02-657636b66bd7n%40googlegroups.com.

Re: [go-nuts] godoc and generic code

2022-11-04 Thread tapi...@gmail.com

You may also try Golds: https://github.com/go101/golds.
Still not perfect in handling custom generic things,
but it is generally usable.

On Friday, November 4, 2022 at 1:26:26 AM UTC+8 Hotei wrote:

> Thanks for the very helpful replies. < go doc -all pkg > should meets my 
> needs for printed documentation.  I guess I will have to weigh the 
> convenience of navigating which the godoc html version provides vs the 
> inconvenience of "instantiating" the methods required by the types [T] I 
> use in this project.  The pkgsite option doesn't seem workable in my case 
> for the reasons eloquently described by one of the posters to issue 49212.  
> At any rate, problem solved and thanks again to the golang-nuts group for 
> the assistance!
>
> On Thursday, November 3, 2022 at 9:32:09 AM UTC-4 Sebastien Binet wrote:
>
>> On Thu Nov 3, 2022 at 14:02 CET, Jan Mercl wrote:
>> > On Thu, Nov 3, 2022 at 12:49 PM Hotei  wrote:
>> >
>> > > I added some generic code to a project and godoc doesn't seem to like 
>> that and stops working when it sees the generics. It's a 4 year old version 
>> of godoc so that's perhaps not a surprise. What is a surprise is that godoc 
>> isn't shipped with go any longer. Is there a version that handles generics 
>> and if so where can I find it? A quick search of github came up empty but I 
>> know things have been moved around so some hints would be much appreciated.
>> >
>> > I'm not in favor of the fact, but It's been deprecated a year ago:
>> > https://github.com/golang/go/issues/49212
>>
>> one can use godocs.io for a maintained "godoc-like" binary:
>>
>> - https://godocs.io/go-hep.org/x/hep/sliceop
>> - https://sr.ht/~sircmpwn/godocs.io/
>>
>> (otherwise, 'go doc' does support "generics")
>>
>> hth,
>> -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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fc14224a-6325-4cd1-a313-af6bfb7e1f67n%40googlegroups.com.

Re: [go-nuts] Re: What's the maximum array length?

2022-10-29 Thread tapi...@gmail.com



On Saturday, October 29, 2022 at 3:52:16 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> You might want to check out the order of messages as seen by google 
> groups: https://groups.google.com/g/golang-nuts/c/mw5f2kyEjpA
> Either your Message was delivered to groups delayed, or Kurtis message was 
> delivered delayed to you.
>

I don't think the order matters at all here. ;)
 

>
> On Sat, Oct 29, 2022 at 9:44 AM T L  wrote:
>
>>
>>
>> On Sat, Oct 29, 2022 at 12:11 PM Kurtis Rader  
>> wrote:
>>
>> Did you not see my reply pointing out the same thing? That is, given a 
>> particular platform and executable format the limit is likely to be much 
>> less than math.MaxInt. Alternatively, was my reply not clear about the 
>> practical versus theoretical limit of the size of an array? Which is not to 
>> say that your reply is invalid. I'm just curious how you view your reply as 
>> being more clear than mine. :-)
>>
>>
>>> On Fri, Oct 28, 2022 at 8:57 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>> The max array length is math.MaxInt. "[math.MaxInt]struct{}" is valid,
>>>> though the practical size of non-zero-size array is hard limited in 
>>>> some way.
>>>>
>>>> On Friday, October 28, 2022 at 9:43:16 AM UTC+8 eric...@arm.com wrote:
>>>>
>>>>> The spec says that " The length is part of the array's type; it must 
>>>>> evaluate to a non-negative constant 
>>>>> <https://go.dev/ref/spec#Constants> representable 
>>>>> <https://go.dev/ref/spec#Representability> by a value of type int. ", 
>>>>> so on a 64-bit environment, I assume that the maximum array length should 
>>>>> be math.MaxInt64, am I right ? But the following code doesn't compile:
>>>>>
>>>>> package main
>>>>> var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}
>>>>>
>>>> -- 
>>>> 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/df18462d-4ec1-4287-ad71-ef4aa0d85a5dn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/df18462d-4ec1-4287-ad71-ef4aa0d85a5dn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>> -- 
>> 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/CAHbs%3DNbmgsUet1GW4AbbBeOQ9xeUZd92ybb28L-m1O8-Ze3CtQ%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/CAHbs%3DNbmgsUet1GW4AbbBeOQ9xeUZd92ybb28L-m1O8-Ze3CtQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/e6d14277-deea-4918-b0f2-6b3ef5280aeen%40googlegroups.com.

[go-nuts] Re: What's the maximum array length?

2022-10-28 Thread tapi...@gmail.com

The max array length is math.MaxInt. "[math.MaxInt]struct{}" is valid,
though the practical size of non-zero-size array is hard limited in some 
way.

On Friday, October 28, 2022 at 9:43:16 AM UTC+8 eric...@arm.com wrote:

> The spec says that " The length is part of the array's type; it must 
> evaluate to a non-negative constant  
> representable  by a value of 
> type int. ", so on a 64-bit environment, I assume that the maximum array 
> length should be math.MaxInt64, am I right ? But the following code doesn't 
> compile:
>
> package main
> var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}
>

-- 
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/df18462d-4ec1-4287-ad71-ef4aa0d85a5dn%40googlegroups.com.

[go-nuts] Re: What is the relationship between go community and goproxy.io

2022-10-10 Thread tapi...@gmail.com



On Monday, October 10, 2022 at 3:11:06 PM UTC+8 Brian Candler wrote:

> > By the go module cache system design, if you trust the server set in 
> your GOSUMDB env var,
> > which is defaulted to sum.golang.org, then it is not a matter whatever 
> proxy server your are using.
>
> From the point of view of downloaded package integrity, yes.
>
> But there are other things an untrustworthy proxy might do - such as 
> tracking what packages and versions you use, identifying which clients are 
> using packages with known security vulnerabilities, selling that data on to 
> third parties etc.
>

This is true for any website we visit daily. :D 

-- 
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/6bcbf0bf-1988-446b-ba80-1093786113b9n%40googlegroups.com.

[go-nuts] Re: What is the relationship between go community and goproxy.io

2022-10-09 Thread tapi...@gmail.com



On Sunday, October 9, 2022 at 11:50:49 PM UTC+8 ljh wrote:

> Hi, community,
>
> I Just saw this site: yunzhanghu.com , is listed as Special Sponsor on 
> goproxy.io homepage.
>
> I'm just curious, is goproxy.io endorsed by The Go Team and is goproxy.io 
> trustworthy? 
>

By the go module cache system design, if you trust the server set in your 
GOSUMDB env var,
which is defaulted to sum.golang.org, then it is not a matter whatever 
proxy server your are using.
 

>
> $ whois goproxy.io
> Registrant Name: REDACTED FOR PRIVACY
>
>

-- 
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/e38557f7-774a-4a36-8d15-5bab40512a51n%40googlegroups.com.

[go-nuts] Re: private go documentation server similar to https://pkg.go.dev

2022-09-11 Thread tapi...@gmail.com

I don't know if it satisfies your need, but you can try Golds: 
https://go101.org/apps-and-libs/golds.html

On Sunday, September 11, 2022 at 5:28:35 AM UTC+8 brainman wrote:

> Hello Everyone,
>
> I would like to run go documentation server that have access to my private 
> code.
>
> Is it possible to do?
>
> I am happy to run the server myself, if it is easy to setup, and if it 
> requires no maintenance.
>
> I am also happy to use external company if they provide that kind of 
> service. Are there companies that do that?
>
> I looked for the source code for
>
> https://pkg.go.dev
>
> and I cannot find it.
>
> Thank you.
>
> Alex
>

-- 
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/d892bd0f-15f3-4b1f-96b8-c9b7e8c050b6n%40googlegroups.com.

[go-nuts] Re: Go 1.19 average goroutine stack

2022-08-22 Thread tapi...@gmail.com



On Saturday, August 20, 2022 at 10:58:10 PM UTC+8 tapi...@gmail.com wrote:

> On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k...@google.com wrote:
>
>> On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com 
>> wrote:
>>
>>> I'm a bit wondering about how the following case will be affected by the 
>>> change:
>>> 1. Initially, there is one goroutine, which stack size is large at the 
>>> time of a GC process.
>>> 2. After the GC process, a large quantity of goroutines start. They all 
>>> need small stacks.
>>>But now the runtime will allocate a very large stack for each of them.
>>>
>>> Then is much memory wasted?
>>>
>>
>> Kind of. Your description is correct, the runtime will allocate larger 
>> stacks for each of the new goroutines. But it doesn't really waste memory, 
>> it just causes the program to reach the next GC earlier. At that GC, stacks 
>> will shrink, as will the start size for subsequent goroutines. So it won't 
>> really waste memory, but waste some CPU for a possibly extra GC.
>> It isn't perfect; for instance we only shrink stacks 2x at each GC, so if 
>> the starting size is way too large it might take a couple GCs to shrink 
>> sufficiently.
>>
>
> I wrote a program to make some tests: https://go.dev/play/p/oDYrAsZz_3i
>
> It looks the new GC pacer doesn't count new stack memory as new allocated 
> heap memory.
> So large new stacks will not make the program to reach the next GC earlier.
>
> Since Go 1.18, the stack sizes (the real sizes, not the 2^n sizes) and 
> global pointers contribute in calculating target heap memory:
> https://go.dev/doc/gc-guide#GOGC, so that large stack sizes will cause 
> large GC intervals.
>

More precisely, Go 1.18 uses the 2^n stack sizes, whereas Go 1.19 uses the 
real stack sizes,
 

>
> It seems that the outputs indicate there are some hidden goroutines which 
> cause the calculated average stack sizes
> much smaller than expected.
>
> BTW, in the runtime docs, https://pkg.go.dev/runtime, "# MB stacks" and "# 
> MB globals" are listed but not shown in the format line.
>
>
>  
>
>>  
>>
>>> Will the stacks of the new goroutines shrink at the next GC process?
>>>
>>
>> Yes. The larger stack sizes are only on goroutine start. The runtime 
>> doesn't forbid shrinking below the start size.
>>  
>>
>>>
>>> On Saturday, August 13, 2022 at 10:00:58 PM UTC+8 lia...@garena.com 
>>> wrote:
>>>
>>>> Hi masters,
>>>>
>>>> As far as I know, go 1.19 supports self-adaptive stack size when 
>>>> spawning a goroutine, which intends to decrease the calling times of 
>>>> morestack that aims to claim more frames from heap.
>>>>
>>>> After each GC happens, Go runtime will calculate the average stack 
>>>> usage and the next time, goroutine would created with such a stack size.
>>>>
>>>> My question is, how do we validate the whole process or check it if 
>>>> works well or not.
>>>> Is there any metric or stack size checking function, or should I use 
>>>> pprof to peek the alloc part ?
>>>>
>>>> Kindly thanks for all
>>>>
>>>> ```
>>>> func main() {
>>>> go func() {
>>>> // spawn a goroutine started from a fixed stack size
>>>> }()
>>>>
>>>> runtime.GC()
>>>>
>>>> go func() {
>>>> // spawn a goroutine started from an avg stack size. 
>>>> }()
>>>> }
>>>> ```
>>>>
>>>>
>>>>

-- 
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/65d0d331-1851-4198-abb5-3fc8be0a69b2n%40googlegroups.com.

[go-nuts] Re: Go 1.19 average goroutine stack

2022-08-20 Thread tapi...@gmail.com

BTW, the outputs of the test program:

$ GODEBUG=gctrace=1  ./main
gc 1 @0.006s 4%: 0.035+1.5+0.006 ms clock, 0.14+0/1.5/2.0+0.024 ms cpu, 
0->0->0 MB, 8 MB goal, 0 MB stacks, 8 MB globals, 4 P (forced)
2022/08/20 22:46:47 2048 1
gc 2 @2.123s 0%: 0.034+2.6+0.008 ms clock, 0.13+0/2.5/7.1+0.035 ms cpu, 
0->0->0 MB, 8 MB goal, 64 MB stacks, 8 MB globals, 4 P (forced)
2022/08/20 22:46:49 8388608 2
GC forced
gc 3 @124.390s 0%: 0.045+5.1+0.010 ms clock, 0.18+0/5.1/0+0.041 ms cpu, 
0->0->0 MB, 63 MB goal, 128 MB stacks, 8 MB globals, 4 P
GC forced
gc 4 @244.411s 0%: 0.072+5.0+0.009 ms clock, 0.28+0/5.0/0+0.038 ms cpu, 
0->0->0 MB, 118 MB goal, 128 MB stacks, 8 MB globals, 4 P
gc 5 @307.129s 0%: 0.076+2.7+0.013 ms clock, 0.30+0/2.7/7.9+0.052 ms cpu, 
0->0->0 MB, 118 MB goal, 128 MB stacks, 8 MB globals, 4 P (forced)
2022/08/20 22:51:56 16777216 3
gc 6 @313.134s 0%: 0.098+2.6+0.011 ms clock, 0.39+0/2.5/7.5+0.044 ms cpu, 
0->0->0 MB, 118 MB goal, 128 MB stacks, 8 MB globals, 4 P (forced)
2022/08/20 22:52:02 16777216 3

On Saturday, August 20, 2022 at 10:58:10 PM UTC+8 tapi...@gmail.com wrote:

> On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k...@google.com wrote:
>
>> On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com 
>> wrote:
>>
>>> I'm a bit wondering about how the following case will be affected by the 
>>> change:
>>> 1. Initially, there is one goroutine, which stack size is large at the 
>>> time of a GC process.
>>> 2. After the GC process, a large quantity of goroutines start. They all 
>>> need small stacks.
>>>But now the runtime will allocate a very large stack for each of them.
>>>
>>> Then is much memory wasted?
>>>
>>
>> Kind of. Your description is correct, the runtime will allocate larger 
>> stacks for each of the new goroutines. But it doesn't really waste memory, 
>> it just causes the program to reach the next GC earlier. At that GC, stacks 
>> will shrink, as will the start size for subsequent goroutines. So it won't 
>> really waste memory, but waste some CPU for a possibly extra GC.
>> It isn't perfect; for instance we only shrink stacks 2x at each GC, so if 
>> the starting size is way too large it might take a couple GCs to shrink 
>> sufficiently.
>>
>
> I wrote a program to make some tests: https://go.dev/play/p/oDYrAsZz_3i
>
> It looks the new GC pacer doesn't count new stack memory as new allocated 
> heap memory.
> So large new stacks will not make the program to reach the next GC earlier.
>
> Since Go 1.18, the stack sizes (the real sizes, not the 2^n sizes) and 
> global pointers contribute in calculating target heap memory:
> https://go.dev/doc/gc-guide#GOGC, so that large stack sizes will cause 
> large GC intervals.
>
> It seems that the outputs indicate there are some hidden goroutines which 
> cause the calculated average stack sizes
> much smaller than expected.
>
> BTW, in the runtime docs, https://pkg.go.dev/runtime, "# MB stacks" and "# 
> MB globals" are listed but not shown in the format line.
>
>
>  
>
>>  
>>
>>> Will the stacks of the new goroutines shrink at the next GC process?
>>>
>>
>> Yes. The larger stack sizes are only on goroutine start. The runtime 
>> doesn't forbid shrinking below the start size.
>>  
>>
>>>
>>> On Saturday, August 13, 2022 at 10:00:58 PM UTC+8 lia...@garena.com 
>>> wrote:
>>>
>>>> Hi masters,
>>>>
>>>> As far as I know, go 1.19 supports self-adaptive stack size when 
>>>> spawning a goroutine, which intends to decrease the calling times of 
>>>> morestack that aims to claim more frames from heap.
>>>>
>>>> After each GC happens, Go runtime will calculate the average stack 
>>>> usage and the next time, goroutine would created with such a stack size.
>>>>
>>>> My question is, how do we validate the whole process or check it if 
>>>> works well or not.
>>>> Is there any metric or stack size checking function, or should I use 
>>>> pprof to peek the alloc part ?
>>>>
>>>> Kindly thanks for all
>>>>
>>>> ```
>>>> func main() {
>>>> go func() {
>>>> // spawn a goroutine started from a fixed stack size
>>>> }()
>>>>
>>>> runtime.GC()
>>>>
>>>> go func() {
>>>> // spawn a goroutine started from an avg stack size. 
>>>> }()
>>>> }
>>>> ```
>>>>
>>>>
>>>>

-- 
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/d185b4fe-2de6-4ef9-94c8-bfd9f14fe1c3n%40googlegroups.com.

[go-nuts] Re: Go 1.19 average goroutine stack

2022-08-20 Thread tapi...@gmail.com



On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k...@google.com wrote:

> On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com wrote:
>
>> I'm a bit wondering about how the following case will be affected by the 
>> change:
>> 1. Initially, there is one goroutine, which stack size is large at the 
>> time of a GC process.
>> 2. After the GC process, a large quantity of goroutines start. They all 
>> need small stacks.
>>But now the runtime will allocate a very large stack for each of them.
>>
>> Then is much memory wasted?
>>
>
> Kind of. Your description is correct, the runtime will allocate larger 
> stacks for each of the new goroutines. But it doesn't really waste memory, 
> it just causes the program to reach the next GC earlier. At that GC, stacks 
> will shrink, as will the start size for subsequent goroutines. So it won't 
> really waste memory, but waste some CPU for a possibly extra GC.
> It isn't perfect; for instance we only shrink stacks 2x at each GC, so if 
> the starting size is way too large it might take a couple GCs to shrink 
> sufficiently.
>

I wrote a program to make some tests: https://go.dev/play/p/oDYrAsZz_3i

It looks the new GC pacer doesn't count new stack memory as new allocated 
heap memory.
So large new stacks will not make the program to reach the next GC earlier.

Since Go 1.18, the stack sizes (the real sizes, not the 2^n sizes) and 
global pointers contribute in calculating target heap memory:
https://go.dev/doc/gc-guide#GOGC, so that large stack sizes will cause 
large GC intervals.

It seems that the outputs indicate there are some hidden goroutines which 
cause the calculated average stack sizes
much smaller than expected.

BTW, in the runtime docs, https://pkg.go.dev/runtime, "# MB stacks" and "# 
MB globals" are listed but not shown in the format line.


 

>  
>
>> Will the stacks of the new goroutines shrink at the next GC process?
>>
>
> Yes. The larger stack sizes are only on goroutine start. The runtime 
> doesn't forbid shrinking below the start size.
>  
>
>>
>> On Saturday, August 13, 2022 at 10:00:58 PM UTC+8 lia...@garena.com 
>> wrote:
>>
>>> Hi masters,
>>>
>>> As far as I know, go 1.19 supports self-adaptive stack size when 
>>> spawning a goroutine, which intends to decrease the calling times of 
>>> morestack that aims to claim more frames from heap.
>>>
>>> After each GC happens, Go runtime will calculate the average stack usage 
>>> and the next time, goroutine would created with such a stack size.
>>>
>>> My question is, how do we validate the whole process or check it if 
>>> works well or not.
>>> Is there any metric or stack size checking function, or should I use 
>>> pprof to peek the alloc part ?
>>>
>>> Kindly thanks for all
>>>
>>> ```
>>> func main() {
>>> go func() {
>>> // spawn a goroutine started from a fixed stack size
>>> }()
>>>
>>> runtime.GC()
>>>
>>> go func() {
>>> // spawn a goroutine started from an avg stack size. 
>>> }()
>>> }
>>> ```
>>>
>>>
>>>

-- 
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/ef1f7e04-439e-4ab5-9143-527935180828n%40googlegroups.com.

[go-nuts] Re: Go 1.19 average goroutine stack

2022-08-17 Thread tapi...@gmail.com

I'm a bit wondering about how the following case will be affected by the 
change:
1. Initially, there is one goroutine, which stack size is large at the time 
of a GC process.
2. After the GC process, a large quantity of goroutines start. They all 
need small stacks.
   But now the runtime will allocate a very large stack for each of them.

Then is much memory wasted? Will the stacks of the new goroutines shrink at 
the next GC process?

On Saturday, August 13, 2022 at 10:00:58 PM UTC+8 lia...@garena.com wrote:

> Hi masters,
>
> As far as I know, go 1.19 supports self-adaptive stack size when spawning 
> a goroutine, which intends to decrease the calling times of morestack that 
> aims to claim more frames from heap.
>
> After each GC happens, Go runtime will calculate the average stack usage 
> and the next time, goroutine would created with such a stack size.
>
> My question is, how do we validate the whole process or check it if works 
> well or not.
> Is there any metric or stack size checking function, or should I use pprof 
> to peek the alloc part ?
>
> Kindly thanks for all
>
> ```
> func main() {
> go func() {
> // spawn a goroutine started from a fixed stack size
> }()
>
> runtime.GC()
>
> go func() {
> // spawn a goroutine started from an avg stack size. 
> }()
> }
> ```
>
>
>

-- 
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/e922b755-8205-462b-91ed-b9391b6fa2b2n%40googlegroups.com.

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

2022-08-15 Thread tapi...@gmail.com

I tend to think it should print 1, as well this one: 
https://go.dev/play/p/bax7CoaSV1d


On Monday, August 15, 2022 at 3:34:35 PM UTC+8 tapi...@gmail.com wrote:

> It would be good if the Memory Model article shows some atomic examples.
>
> On Monday, August 15, 2022 at 3:06:58 PM UTC+8 ma...@changkun.de wrote:
>
>> I think the new memory model does not guarantee this program always 
>> prints 1:
>>
>> 1. There is no synchronization guarantee between line 13 and line 14
>> as these atomic operations are manipulated on the different memory
>> locations.
>> 2. It is *not* prohibited for the compiler to switch line 13 and line
>> 14 (as I read from section https://go.dev/ref/mem#badcompiler) because
>> of the above reason, and also, there is no order between line 13 and
>> line 20. So this is possible: line 14 < line 18 < line 20 < line 13.
>> 3. Depending on the memory layout of a and b, if they are on the same
>> cache line, then the program will always print 1.
>>
>>
>> On Mon, Aug 15, 2022 at 8:48 AM 'Axel Wagner' via golang-nuts
>>  wrote:
>> >
>> > Why wouldn't it?
>> >>
>> >> If the effect of an atomic operation A is observed by atomic operation 
>> B, then A is synchronized before B.
>> >
>> > To me, it seems pretty clear that it will. Line 13 is synchronized 
>> before line 14, which is synchronized before any load observing its effects 
>> (i.e. any execution of line 18 which runs into the branch) - and such a 
>> load is synchronized before the load in line 20.
>> >
>> > Therefore, the store in Line 13 is synchronized before the load in line 
>> 20.
>> >
>> >
>> > On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com  
>> wrote:
>> >>
>> >> By the latest version of Go Memory Model article: 
>> https://go.dev/ref/mem, will the following program always print 1?
>> >>
>> >> https://go.dev/play/p/RICYGip5y8M
>> >>
>> >> --
>> >> 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/4d9b8130-d06c-4519-9b99-d161e922d8f6n%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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHpwchwjAMtXNtpVmhb42Ncw9ENKhz5xH9Sv1z_-DMrRA%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/0ea1f1a1-fee3-4c2a-8dcb-f7bbbc946812n%40googlegroups.com.

[go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

2022-08-15 Thread tapi...@gmail.com

By the latest version of Go Memory Model article: https://go.dev/ref/mem, 
will the following program always print 1?

https://go.dev/play/p/RICYGip5y8M

-- 
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/4d9b8130-d06c-4519-9b99-d161e922d8f6n%40googlegroups.com.

Re: [go-nuts] Is there a compiler directive to use the Go version set in go.mod instead of the current toolchain version?

2022-05-10 Thread tapi...@gmail.com



On Tuesday, May 10, 2022 at 12:19:57 PM UTC+8 Amnon wrote:

> OT, but why do you want to support the Go 1.15 toolchain?
> 1.15 and 1.16 are no longer supported upstream, so will not get essential 
> security fixes.
> Why not just ask your users to upgrade to 1.18.1?
>

I can recommend but not force them to use a recent version.
And this is not a 1.15/1.16 specific problem.
 

>
> On Tuesday, 10 May 2022 at 01:24:12 UTC+1 tapi...@gmail.com wrote:
>
>> On Tuesday, May 10, 2022 at 1:46:35 AM UTC+8 Ian Lance Taylor wrote:
>>
>>> On Mon, May 9, 2022 at 10:18 AM tapi...@gmail.com  
>>> wrote: 
>>> > 
>>> > I have a project using go1.16 embedding feature. 
>>> > The project supports Go toolchain 1.15, by using "//go:build !go1.16" 
>>> directive. 
>>> > 
>>> > Now I have upgraded the toolchain to v1.18.1, 
>>> > And I want to debug the non-embedding flow of the project. 
>>> > Changing the go version in go.mod doesn't help. 
>>> > 
>>> > Do I have to install back Go toolchain 1.15? 
>>>
>>> I don't think that what you want to do is supported. I recommend that 
>>> you install 1.15 somewhere. 
>>>
>>> That said, you could try "go build -gcflags=-lang=go1.15". 
>>>
>>> Ian 
>>>
>>
>>  "go build -gcflags=-lang=go1.15" doesn't work too.
>> OK, I will try to install 1.15 alongside.
>>
>

-- 
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/dc3fb718-6adb-479f-b545-6fe17f937fden%40googlegroups.com.

Re: [go-nuts] Is there a compiler directive to use the Go version set in go.mod instead of the current toolchain version?

2022-05-09 Thread tapi...@gmail.com



On Tuesday, May 10, 2022 at 1:46:35 AM UTC+8 Ian Lance Taylor wrote:

> On Mon, May 9, 2022 at 10:18 AM tapi...@gmail.com  
> wrote: 
> > 
> > I have a project using go1.16 embedding feature. 
> > The project supports Go toolchain 1.15, by using "//go:build !go1.16" 
> directive. 
> > 
> > Now I have upgraded the toolchain to v1.18.1, 
> > And I want to debug the non-embedding flow of the project. 
> > Changing the go version in go.mod doesn't help. 
> > 
> > Do I have to install back Go toolchain 1.15? 
>
> I don't think that what you want to do is supported. I recommend that 
> you install 1.15 somewhere. 
>
> That said, you could try "go build -gcflags=-lang=go1.15". 
>
> Ian 
>

 "go build -gcflags=-lang=go1.15" doesn't work too.
OK, I will try to install 1.15 alongside.

-- 
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/c06cd282-c306-44c3-91e2-7d820ff78f2an%40googlegroups.com.

[go-nuts] Is there a compiler directive to use the Go version set in go.mod instead of the current toolchain version?

2022-05-09 Thread tapi...@gmail.com

I have a project using go1.16 embedding feature.
The project supports Go toolchain 1.15, by using "//go:build !go1.16" 
directive.

Now I have upgraded the toolchain to v1.18.1, 
And I want to debug the non-embedding flow of the project.
Changing the go version in go.mod doesn't help.

Do I have to install back Go toolchain 1.15?

-- 
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/9e746abf-41a4-4bb5-91ad-c45f7591c5a8n%40googlegroups.com.

Re: [go-nuts] Refactor to use generics to have a single Make

2022-05-03 Thread tapi...@gmail.com



On Wednesday, May 4, 2022 at 7:01:48 AM UTC+8 se...@liao.dev wrote:

> right now it only works if the structs are actually identical:
> https://go.dev/play/p/tMG3SYG5fLN
>
> - sean
>
>
Though accessing fields is still not allowed.
 

>
> On Tue, May 3, 2022 at 8:06 PM sbezverk  wrote:
>
>> Hello,
>>
>>  
>>
>> I am starting to learn generics and I was wondering if the following code 
>> could be refactored to use genercis, in order to avoid using per type 
>> Make() method.
>>
>>  
>>
>> https://go.dev/play/p/gE4Z6Zj19Is
>>
>>  
>>
>> I have 3 identical structs, they are defined with different types and 
>> used in other types by their unique types. The function to create all 3 
>> types can be consolidated as the actual structure of is the same.
>>
>>  
>>
>> I am curious it would be possible to leverage generics for this. I have 
>> made an attempt but I still need to use per type Make method.
>>
>>  
>>
>> Thank you and appreciate a lot your help.
>>
>>  
>>
>> Serguei
>>
>> -- 
>> 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/D41C14EF-35D1-434F-A719-1E8C88D90C0F%40gmail.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/4a99ffe9-8a38-45b7-ae6d-9c12ef6cf058n%40googlegroups.com.

Re: [go-nuts] Are the two constraints equivalent to each other?

2022-04-02 Thread tapi...@gmail.com

Ah, I forgot that point.
Thanks for the explanation!

On Saturday, April 2, 2022 at 10:00:27 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> Ptr[int] is a defined type, `*int` is not. So the two types are not the 
> same and this is working as intended.
>
> On Sat, Apr 2, 2022 at 3:50 PM tapi...@gmail.com  
> wrote:
>
>>
>> package main
>>
>> type Ptr[E any] *E
>>
>> type MyConstraint interface {
>> Ptr[int]
>> }
>>
>> type YourConstraint interface {
>> *int
>> }
>>
>> func foo[T MyConstraint](x T) {
>> }
>>
>> func bar[T YourConstraint](x T) {
>> }
>>
>> func main() {
>> var x = new(int)
>> foo(x) // *int does not implement MyConstraint
>> bar(x)
>> }
>>
>> -- 
>> 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/e252f550-b5ae-43ca-b25d-12ce076fd74cn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/e252f550-b5ae-43ca-b25d-12ce076fd74cn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/4f08c0cb-a03e-4de2-b59d-c8edffe42d52n%40googlegroups.com.

[go-nuts] Are the two constraints equivalent to each other?

2022-04-02 Thread tapi...@gmail.com


package main

type Ptr[E any] *E

type MyConstraint interface {
Ptr[int]
}

type YourConstraint interface {
*int
}

func foo[T MyConstraint](x T) {
}

func bar[T YourConstraint](x T) {
}

func main() {
var x = new(int)
foo(x) // *int does not implement MyConstraint
bar(x)
}

-- 
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/e252f550-b5ae-43ca-b25d-12ce076fd74cn%40googlegroups.com.

Re: [go-nuts] Unexpected order of global variable declaration during package initialization

Aha, sorry, the file order really matters here.
But for this specified case, it should not.

That's not right. I remembered in an issue thread, it is mentioned that the 
order should be

1. D is not ready (because it depends on A)
2. A is ready, so it is initialized: it gets value 3.
4. B is initialized. It gets value 2
5. C is initialized. It gets value 1
3. Now D is the earliest variable which is ready, so D is initialized. It 
gets value 1, and A is set to 1.

On Thursday, March 24, 2022 at 8:23:14 PM UTC+8 Brian Candler wrote:

> Ugh, quoting got broken there.
>
> $ go run rewritten_f1.go f2.go
> Init A
> Init B
> Init C
> 1   4   3
>
> $ go run f2.go rewritten_f1.go
> Init A
> Init B
> Init C
> 1   2   1
>
> Hopefully that will show properly.
>

-- 
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/44b3e727-53e9-4af1-8ba5-9e6d9029f771n%40googlegroups.com.

Re: [go-nuts] Is it safe to say two unname interface types are identical if their type sets are identicial?

Then I think interface{int; m()} and interface{bool;; m()} should be 
identical.
Because their type sets are both empty..

On Thursday, March 24, 2022 at 7:38:10 PM UTC+8 Jan Mercl wrote:

> On Thu, Mar 24, 2022 at 11:58 AM tapi...@gmail.com  
> wrote:
>
> https://go.dev/ref/spec#Type_identity
>
> """"
> Two interface types are identical if they define the same type set.
> """"
>

-- 
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/74f1adbe-020b-401e-b897-895f4d03a312n%40googlegroups.com.

Re: [go-nuts] Unexpected order of global variable declaration during package initialization

BTW, the rewritten version outputs

Init A
Init B
Init C
1   4   3

On my machine (go1.18 linux/amd64).
On Thursday, March 24, 2022 at 7:30:37 PM UTC+8 tapi...@gmail.com wrote:

> > 2. A < D < B < C - happens when f2.go is passed first to the compiler. 
> In this case, the *expected output *would be "1 2 1". However, the *actual 
> output* is "1 2 3".
>
> This is not true by my understanding of the spec.
> https://go.dev/ref/spec#Package_initialization
>
> If f2.go is passed first, then the order of uninitialized variables is D < 
> A < B < C.
> As D depends on A, so D is not initialized in the first initialization 
> cycle.
> In the first initialization cycle, A, B, and C and initialized as 3, 4, 
> and 3.
> In the second initialization cycle, D is initialized as 1 and A is changed 
> to 1.
> So the output should be 1 4 3.
>
> The same output is for the case if f1.go is passed first.
>
> On Thursday, March 24, 2022 at 5:24:09 AM UTC+8 Ian Lance Taylor wrote:
>
>> On Wed, Mar 23, 2022 at 2:01 PM Joao Carlos  
>> wrote: 
>> > 
>> > I'm currently observing a behavior in the package initialization that 
>> looks incompatible with the Go language specification. 
>> > Let's consider the following two .go files which are in the same 
>> package 
>> > 
>> > f1.go 
>> > package main 
>> > 
>> > var A int = 3 
>> > var B int = A + 1 
>> > var C int = A 
>> > 
>> > f2.go 
>> > package main 
>> > 
>> > import "fmt" 
>> > 
>> > var D = f() 
>> > 
>> > func f() int { 
>> > A = 1 
>> > return 1 
>> > } 
>> > 
>> > func main() { 
>> > fmt.Println(A, " ", B, " ", C) 
>> > } 
>> > 
>> > According to the Go language specification, "package-level variable 
>> initialization proceeds stepwise, with each step selecting the variable 
>> earliest in declaration order which has no dependencies on uninitialized 
>> variables". 
>> > 
>> > As such, I would expect two possible orders in which the global 
>> variables can be initialized: 
>> > 1. A < B < C < D - happens when you compile the project by passing 
>> f1.go first to the compiler, followed by f2.go . In this case, the output 
>> is "1 4 3" 
>> > 2. A < D < B < C - happens when f2.go is passed first to the compiler. 
>> In this case, the expected output would be "1 2 1". However, the actual 
>> output is "1 2 3". 
>> > 
>> > Adding to this, I observed that if we rewrite f1.go to the following, 
>> the program now has the expected behavior when we pass f2.go first to the 
>> compiler. 
>> > 
>> > rewritten f1.go 
>> > package main 
>> > 
>> > import "fmt" 
>> > 
>> > var A int = initA() 
>> > var B int = initB() 
>> > var C int = initC() 
>> > 
>> > func initA() int { 
>> > fmt.Println("Init A") 
>> > return 3 
>> > } 
>> > 
>> > func initB() int { 
>> > fmt.Println("Init B") 
>> > return A + 1 
>> > } 
>> > 
>> > func initC() int { 
>> > fmt.Println("Init C") 
>> > return A 
>> > } 
>> > 
>> > Output 
>> > Init A 
>> > Init B 
>> > Init C 
>> > 1 2 1 
>> > 
>> > I observed this behavior in multiple versions of Go, including: 
>> > - go1.16.4 darwin/amd64 
>> > - go1.17.2 linux/amd64 
>> > - go1.18 linux/amd64 
>> > 
>> > Is this the expected behavior? Am I overlooking any details in the Go 
>> language specification or in the Go memory model? Or is this a bug in the 
>> compiler? 
>>
>> I think you're right: I think this is a bug. 
>>
>> Interestingly, I think the runtime package may rely on this bug. In 
>> the runtime package I see 
>>
>> var maxSearchAddr = maxOffAddr 
>> var maxOffAddr = offAddr{(((1 << heapAddrBits) - 1) + arenaBaseOffset) 
>> & uintptrMask} 
>>
>> and pageAlloc.Init, which is called by mheap.init which is called by 
>> mallocinit which is called by schedinit before package initializers 
>> are run. So the compiler is implementing an optimization to 
>> initialize maxSearchAddr before running package initialization 
>> routines, which I suppose is OK provided it that it can prove that the 
>> variable is never set by any function run during package 
>> initialization. 
>>
>> Want to open a bug report at https://go.dev/issue? Thanks. 
>>
>> 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/47e3c43d-65f6-4743-b9b9-60626c9142e0n%40googlegroups.com.

Re: [go-nuts] Unexpected order of global variable declaration during package initialization

> 2. A < D < B < C - happens when f2.go is passed first to the compiler. In 
this case, the *expected output *would be "1 2 1". However, the *actual 
output* is "1 2 3".

This is not true by my understanding of the spec.
https://go.dev/ref/spec#Package_initialization

If f2.go is passed first, then the order of uninitialized variables is D < 
A < B < C.
As D depends on A, so D is not initialized in the first initialization 
cycle.
In the first initialization cycle, A, B, and C and initialized as 3, 4, and 
3.
In the second initialization cycle, D is initialized as 1 and A is changed 
to 1.
So the output should be 1 4 3.

The same output is for the case if f1.go is passed first.

On Thursday, March 24, 2022 at 5:24:09 AM UTC+8 Ian Lance Taylor wrote:

> On Wed, Mar 23, 2022 at 2:01 PM Joao Carlos  wrote:
> >
> > I'm currently observing a behavior in the package initialization that 
> looks incompatible with the Go language specification.
> > Let's consider the following two .go files which are in the same package
> >
> > f1.go
> > package main
> >
> > var A int = 3
> > var B int = A + 1
> > var C int = A
> >
> > f2.go
> > package main
> >
> > import "fmt"
> >
> > var D = f()
> >
> > func f() int {
> > A = 1
> > return 1
> > }
> >
> > func main() {
> > fmt.Println(A, " ", B, " ", C)
> > }
> >
> > According to the Go language specification, "package-level variable 
> initialization proceeds stepwise, with each step selecting the variable 
> earliest in declaration order which has no dependencies on uninitialized 
> variables".
> >
> > As such, I would expect two possible orders in which the global 
> variables can be initialized:
> > 1. A < B < C < D - happens when you compile the project by passing f1.go 
> first to the compiler, followed by f2.go . In this case, the output is "1 4 
> 3"
> > 2. A < D < B < C - happens when f2.go is passed first to the compiler. 
> In this case, the expected output would be "1 2 1". However, the actual 
> output is "1 2 3".
> >
> > Adding to this, I observed that if we rewrite f1.go to the following, 
> the program now has the expected behavior when we pass f2.go first to the 
> compiler.
> >
> > rewritten f1.go
> > package main
> >
> > import "fmt"
> >
> > var A int = initA()
> > var B int = initB()
> > var C int = initC()
> >
> > func initA() int {
> > fmt.Println("Init A")
> > return 3
> > }
> >
> > func initB() int {
> > fmt.Println("Init B")
> > return A + 1
> > }
> >
> > func initC() int {
> > fmt.Println("Init C")
> > return A
> > }
> >
> > Output
> > Init A
> > Init B
> > Init C
> > 1 2 1
> >
> > I observed this behavior in multiple versions of Go, including:
> > - go1.16.4 darwin/amd64
> > - go1.17.2 linux/amd64
> > - go1.18 linux/amd64
> >
> > Is this the expected behavior? Am I overlooking any details in the Go 
> language specification or in the Go memory model? Or is this a bug in the 
> compiler?
>
> I think you're right: I think this is a bug.
>
> Interestingly, I think the runtime package may rely on this bug. In
> the runtime package I see
>
> var maxSearchAddr = maxOffAddr
> var maxOffAddr = offAddr{(((1 << heapAddrBits) - 1) + arenaBaseOffset)
> & uintptrMask}
>
> and pageAlloc.Init, which is called by mheap.init which is called by
> mallocinit which is called by schedinit before package initializers
> are run. So the compiler is implementing an optimization to
> initialize maxSearchAddr before running package initialization
> routines, which I suppose is OK provided it that it can prove that the
> variable is never set by any function run during package
> initialization.
>
> Want to open a bug report at https://go.dev/issue? Thanks.
>
> 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/f37ab0a1-d287-405f-9e2a-514ab6e60acan%40googlegroups.com.

[go-nuts] Is it safe to say two unname interface types are identical if their type sets are identicial?


.

-- 
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/ad3a0670-a7a7-49ad-9e85-cbdae98cacb7n%40googlegroups.com.

Re: [go-nuts] Re: Is there a way to eliminate the code repetition in the code?

2022-03-22 Thread tapi...@gmail.com

Is it hard to add two predeclared constraints, convertibleFrom and 
convertibleTo, just like comparable?

On Tuesday, March 22, 2022 at 11:07:41 PM UTC+8 Ian Lance Taylor wrote:

> On Tue, Mar 22, 2022 at 6:01 AM tapi...@gmail.com  
> wrote:
> >
> >
> >
> > On Monday, March 21, 2022 at 3:29:44 PM UTC+8 Henry wrote:
> >>
> >> Perhaps something like this?
> >> ```go
> >> func Convert[T, A any](src []T, converter func(T) A) []A {
> >> result := make([]A, len(src))
> >> for index, a := range src {
> >> result[index] = converter(a)
> >> }
> >> return result
> >> }
> >> ```
> >> See https://play.golang.com/p/rq89Wposc-D
> >
> >
> > It might reduce some code (surely not eliminate), but it is very 
> ungraceful.
> >
> > The current constraint design lacks of two abilities:
> > 1. The ability of specifying a type argument must be an interface type.
> > 2. The ability of specifying a type argument must not be an interface 
> type.
> >
> > I except an implementation like
> >
> > func ConvertSlice[From implements(To), To interface](vs []From) []To {
> > var r = make([]To, len(vs))
> > for i := range vs {
> > r[i] = vs[i]
> > }
> > return r
> > }
>
> I think it would be simpler to look for a way to express that one type
> parameter is convertible to another type parameter, as I suggested
> earlier. I don't see a need to distinguish between interface and
> non-interface types, or to introduce the notion of whether one type
> parameter implements another.
>
> 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/9d1029ae-95ff-42be-9ae1-5bff74f5111bn%40googlegroups.com.

[go-nuts] Re: Is there a way to eliminate the code repetition in the code?

2022-03-22 Thread tapi...@gmail.com



On Monday, March 21, 2022 at 3:29:44 PM UTC+8 Henry wrote:

> Perhaps something like this?
> ```go
> func Convert[T, A any](src []T, converter func(T) A) []A {
> result := make([]A, len(src))
> for index, a := range src {
> result[index] = converter(a)
> }
> return result
> }
> ```
> See https://play.golang.com/p/rq89Wposc-D
>

It might reduce some code (surely not eliminate), but it is very ungraceful.

The current constraint design lacks of two abilities:
1. The ability of specifying a type argument must be an interface type.
2. The ability of specifying a type argument must not be an interface type.

I except an implementation like

func ConvertSlice[From implements(To), To interface](vs []From) []To {
var r = make([]To, len(vs))
for i := range vs {
r[i] = vs[i]
}
return r
}

 

>
>
> On Sunday, March 20, 2022 at 11:36:27 PM UTC+7 tapi...@gmail.com wrote:
>
>>
>>
>> package main
>>
>> type A interface {
>> Ma()
>> }
>>
>> type B interface {
>> Mb()
>> }
>>
>> type Ta struct { A }
>>
>> type Tb struct { B }
>>
>> func ConvertSliceToA[From A](vs []From) []A {
>> var r = make([]A, len(vs))
>> for i := range vs {
>> r[i] = vs[i]
>> }
>> return r
>> }
>>
>> func ConvertSliceToB[From B](vs []From) []B {
>> var r = make([]B, len(vs))
>> for i := range vs {
>> r[i] = vs[i]
>> }
>> return r
>> }
>>
>> func main() {
>> var x [100]Ta
>> var _ = ConvertSliceToA(x[:])
>> 
>> var y [100]Tb
>> var _ = ConvertSliceToB(y[:])
>> }
>>
>

-- 
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/10d8fe73-3249-48f7-9eb1-e303a4fec69dn%40googlegroups.com.

[go-nuts] Re: type parameters and named type

2022-03-20 Thread tapi...@gmail.com

> *type parameters *itself is not a type, but a list of type parameters. 

true. The spec means a single type parameter is a named type.

On Monday, March 21, 2022 at 12:12:26 AM UTC+8 xiej...@gmail.com wrote:

> Hi there. 
>
> I am reading go spec. When hit the "Types" section, 
>
> https://go.dev/ref/spec#Types
>
> it stated "Predeclared types, defined types, and type parameters are 
> called named types."
>
> I wonder why "type parameters" is "named type". To find the definition of 
> this term, I found section 
>
> https://go.dev/ref/spec#Type_parameter_declarations
>
> As quoted, "A type parameter list declares the *type parameters* of a 
> generic function or type declaration. ". My interpretation is: *type 
> parameters *itself is not a type, but a list of type parameters. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/449d6c55-3a04-4422-8fd8-fd87bd8a4d5cn%40googlegroups.com.

[go-nuts] Is there a way to eliminate the code repetition in the code?

2022-03-20 Thread tapi...@gmail.com



package main

type A interface {
Ma()
}

type B interface {
Mb()
}

type Ta struct { A }

type Tb struct { B }

func ConvertSliceToA[From A](vs []From) []A {
var r = make([]A, len(vs))
for i := range vs {
r[i] = vs[i]
}
return r
}

func ConvertSliceToB[From B](vs []From) []B {
var r = make([]B, len(vs))
for i := range vs {
r[i] = vs[i]
}
return r
}

func main() {
var x [100]Ta
var _ = ConvertSliceToA(x[:])

var y [100]Tb
var _ = ConvertSliceToB(y[:])
}

-- 
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/fa05695e-f891-41e3-a647-fff56b6b112cn%40googlegroups.com.

[go-nuts] The core type definition might be not right

2022-03-03 Thread tapi...@gmail.com


The tip spec states that the core type of a constraint is born from the 
type set of the constraint. https://tip.golang.org/ref/spec#Core_types

So the C constraint in the following program should have no core type,
because its type set is blank. But the foo function compiles okay,
which indicates the current implementation thinks C has a core type.

Maybe, the core type of a constraint should be born from the specific types 
of the constraint?

package main

func main() {}

type C interface {
map[int]int
M()
}

func foo[T C]() {
var _ = make(T)
}





-- 
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/10f7aca4-2990-483c-b0ee-c9e820f0b863n%40googlegroups.com.

Re: [go-nuts] Re: An mistake in tip spec?

Thanks for the reply, gri.

The latest generics design and implementation are much more beautiful than 
I expected, though I still think there are many restrictions.

BTW, it looks the following line in spec becomes depreciated now, as now 
any type could be embedded in interfaces.

In a slightly more general form an interface T may use a (possibly 
qualified) interface type name E as an interface element. This is called 
*embedding* interface E in T.
On Friday, January 7, 2022 at 9:34:41 AM UTC+8 gri wrote:

> Thanks for raising this issue. This is clearly a bug in the spec, or at 
> the very least "an imprecision". Hopefully this is better: 
> https://go-review.googlesource.com/c/go/+/375799 .
>
> The set of specific types is an approximation for the actual type set. In 
> practice we only need to consider those explicitly mentioned types. If the 
> type set is infinite, we can't do much (with respect to operations). To 
> make that simple elsewhere in the spec we want the set of specific types be 
> empty in that case. An alternative approach might be to say the set of 
> specific types is infinite in that case and exclude such infinite sets 
> where we look at specific types.
>
> - gri
>
> On Thursday, January 6, 2022 at 1:23:31 PM UTC-8 axel.wa...@googlemail.com 
> wrote:
>
>> The more I think about it, the more I'm inclined to agree that there is 
>> something wrong with the spec (and maybe the idea of sets of specific types 
>> in general).
>> Because what's the set of specific types of `interface { int | any }`? 
>> From the definition, it should be `int` - the union with an empty set is a 
>> no-op. But the *type set* of that is all types. Which means that this 
>> should be allowed, as per the spec, which is obviously nonsense:
>>
>> type C interface {
>> int | any
>> }
>>
>> func F[T C](v T) {
>> fmt.Println(int(v))
>> }
>>
>> So, logically, the type set of an interface type without type elements 
>> should really be the set of all types (or rather "the set of all underlying 
>> types"), not the empty set, for the algorithm to make sense. In that case, 
>> the specific types of `int | any` are the set of all types and the specific 
>> types of `int ; any` is `int`.
>>
>> I'm not sure if this would be sound, though, as we now get back to the 
>> situation of reducing back from the set of all types to some subset. Maybe 
>> the new restrictions put in place (namely that interfaces with methods 
>> can't appear in unions) are enough to make this easy to manage. I don't 
>> know. Thinking through that would take time.
>>
>> On Thu, Jan 6, 2022 at 8:37 PM Ian Lance Taylor  wrote:
>>
>>> On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner
>>>  wrote:
>>> >
>>> > On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor  
>>> wrote:
>>> >>
>>> >> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
>>> >>  wrote:
>>> >> >
>>> >> > • From the definition of type elements, we can see that an embedded 
>>> interface type is a type element. Therefore, `any` is a type element.
>>> >> > • `any` is an alias for `interface{}`, therefore it is a type 
>>> without any type elements, therefore the set of its specific types is empty 
>>> ("For an interface with no type elements, 푆 is the empty set.").
>>> >> > • `interface{ int; any }` is a type with two type elements. "For an 
>>> interface with type elements, 푆 is the intersection of the specific types 
>>> of its type elements.". Intersecting with an empty set (the specific types 
>>> of `any`) gives an empty set
>>> >> > • Therefore, the set of specific types of `interface{ int; any }` 
>>> is the empty set.
>>> >>
>>> >> That doesn't seem right.  "any" is an interface type and writing
>>> >> "interface { any }" just embeds the empty interface, which has no
>>> >> effect.
>>> >
>>> >
>>> > I think it has no effect on the type set. But it has an effect on the 
>>> set of specific types.
>>> >
>>> > I believe both the rule "for an interface type without type elements S 
>>> is empty" and the rule "for an interface type with type elements, S is the 
>>> intersection of the specific types of its type elements" are vital to the 
>>> working of S - they are, what makes the set easily computable.
>>> >
>>> > To answer the question from your comment in the CL: I believe the 
>>> grammar is very unambiguous about `any` being a type element:
>>> >
>>> >> InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
>>> >> InterfaceElem = MethodElem | TypeElem .
>>> >> MethodElem = MethodName Signature .
>>> >> MethodName = identifier .
>>> >> TypeElem = TypeTerm { "|" TypeTerm } .
>>> >> TypeTerm = Type | UnderlyingType .
>>> >> UnderlyingType = "~" Type .
>>> >
>>> >
>>> > There is no signature, so it's not a MethodElem. Therefore it must be 
>>> a TypeElem.
>>>
>>> Yeah, I think there is something wrong in the current spec.  It can't
>>> be the case that embedding an interface eliminates all specific types.
>>>
>>> Ian
>>>
>>

-- 
You received this message because you are

[go-nuts] Re: An mistake in tip spec?



On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>>
>>> No, the mistake is in your reading of the spec.  You are complaining 
>>> about this line:
>>>
>>> interface{ int; any } // no specific types (intersection is empty)
>>>
>>> The spec makes it clear that:
>>> 1. "any" is short for "interface {}"
>>> 2. "interface {}" has no *specific types*
>>>
>>>
>> I think your logic mistake here is that the operands of the union and 
>> intersection operations are type sets, instead of specific types.
>>
>
> This conclusion is not very precise. More precisely, the operands of the 
> union and intersection operations
> could be either type set or specific types, but interface types don't 
> participate in calculations of specific types.
>

This is still not precise. More precisely speaking, in calculations of 
specific types,
interface types don't participate in intersection operations,
and only "any" (interface{}) is allowed to participate in union operations.
The result of a union operation with any as an operand is a blank set.
 

>  
>
>>  
>>
>>> You are taking the intersection of the set of one type (int) with the 
>>> empty set, and therefore the result is the empty set.  Exactly as the 
>>> comment says.
>>>
>>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>>>
>>>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>>>
>>>>> 1. interface { a;b } is intersection. The "Intersection" between two 
>>>>> sets means things which exist in both sets simultaneously.
>>>>> 2. interface { a|b } is union.  "Union" means a set of things which 
>>>>> which exist in set A *or* set B.
>>>>>
>>>>> Quoting from the spec:
>>>>> *"the predeclared type *any* is an alias for the empty interface." *
>>>>> *"interface{} // no specific types"*
>>>>> *"For an interface with type elements, 푆 is the intersection of the 
>>>>> specific types of its type elements."*
>>>>>
>>>>> Can you see now?
>>>>>
>>>>
>>>> The explanation is as what I think.
>>>> But what is your conclusion? Is it a mistake in spec?
>>>>
>>>

-- 
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/1795770f-27d4-41fe-b02f-74f2e43d6528n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?



On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>
>> No, the mistake is in your reading of the spec.  You are complaining 
>> about this line:
>>
>> interface{ int; any } // no specific types (intersection is empty)
>>
>> The spec makes it clear that:
>> 1. "any" is short for "interface {}"
>> 2. "interface {}" has no *specific types*
>>
>>
> I think your logic mistake here is that the operands of the union and 
> intersection operations are type sets, instead of specific types.
>

This conclusion is not very precise. More precisely, the operands of the 
union and intersection operations
could be either type set or specific types, but interface types don't 
participate in calculations of specific types.
 

>  
>
>> You are taking the intersection of the set of one type (int) with the 
>> empty set, and therefore the result is the empty set.  Exactly as the 
>> comment says.
>>
>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>>
>>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>>
>>>> 1. interface { a;b } is intersection. The "Intersection" between two 
>>>> sets means things which exist in both sets simultaneously.
>>>> 2. interface { a|b } is union.  "Union" means a set of things which 
>>>> which exist in set A *or* set B.
>>>>
>>>> Quoting from the spec:
>>>> *"the predeclared type *any* is an alias for the empty interface." *
>>>> *"interface{} // no specific types"*
>>>> *"For an interface with type elements, 푆 is the intersection of the 
>>>> specific types of its type elements."*
>>>>
>>>> Can you see now?
>>>>
>>>
>>> The explanation is as what I think.
>>> But what is your conclusion? Is it a mistake in spec?
>>>
>>

-- 
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/a44f0c52-dde5-4d86-b9e7-7fa097a1dfden%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

sorry again. It should be "the type set and specific types of interface{ 
int; any } are both {int}."

On Thursday, January 6, 2022 at 9:45:35 PM UTC+8 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote:
>>
>>> So to be more specific, I think you're asking why this code works:
>>> https://gotipplay.golang.org/p/kuYzzx4EJY1
>>>
>>> Sorry, I made a mistake in interpreting the spec.  It also says:
>>>
>>> "The type set of the empty interface is the set of all types."
>>>
>>> Therefore, the type set of the intersection { int; any } is int - and 
>>> hence f[int] is allowed.
>>>
>>> But the set of specific types 
>>> <https://tip.golang.org/ref/spec#Structure_of_interfaces> is empty:
>>>
>>> "An interface specification which contains type elements 
>>> <https://tip.golang.org/ref/spec#Interface_types> defines a (possibly 
>>> empty) set of *specific types*. Loosely speaking, these are the 
>>> types T that appear in the interface definition in terms of the form T, ~T, 
>>> or in unions of such terms."
>>>
>>> The type set and the set of specific types can be different. Examples 
>>> are given where one is empty and the other is non-empty:
>>>
>>> interface{ int; m() } // *[specific type]* int (but type set is empty 
>>> because int has no method m)
>>> interface{ int; any } // no specific types (intersection is empty) *[even 
>>> though the type set is not empty]*
>>>
>>> *Items in [italics/brackets] are my additions*
>>>
>>
>> > The type set and the set of specific types can be different
>>
>> This is true.
>>
>> > interface{ int; any } // no specific types (intersection is empty) *[even 
>> though the type set is not empty]*
>>
>> I don't think this is true. In my opinion, the method set of specific 
>> types of interface{ int; any } are both {int}.
>>
>
> sorry a typo:  it should be  
>
> the method set and specific types of interface{ int; any } are both {int}.
>

-- 
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/d25a0a6f-95f7-4d04-9321-486789d02339n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?



On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote:
>
>> So to be more specific, I think you're asking why this code works:
>> https://gotipplay.golang.org/p/kuYzzx4EJY1
>>
>> Sorry, I made a mistake in interpreting the spec.  It also says:
>>
>> "The type set of the empty interface is the set of all types."
>>
>> Therefore, the type set of the intersection { int; any } is int - and 
>> hence f[int] is allowed.
>>
>> But the set of specific types 
>> <https://tip.golang.org/ref/spec#Structure_of_interfaces> is empty:
>>
>> "An interface specification which contains type elements 
>> <https://tip.golang.org/ref/spec#Interface_types> defines a (possibly 
>> empty) set of *specific types*. Loosely speaking, these are the 
>> types T that appear in the interface definition in terms of the form T, ~T, 
>> or in unions of such terms."
>>
>> The type set and the set of specific types can be different. Examples are 
>> given where one is empty and the other is non-empty:
>>
>> interface{ int; m() } // *[specific type]* int (but type set is empty 
>> because int has no method m)
>> interface{ int; any } // no specific types (intersection is empty) *[even 
>> though the type set is not empty]*
>>
>> *Items in [italics/brackets] are my additions*
>>
>
> > The type set and the set of specific types can be different
>
> This is true.
>
> > interface{ int; any } // no specific types (intersection is empty) *[even 
> though the type set is not empty]*
>
> I don't think this is true. In my opinion, the method set of specific 
> types of interface{ int; any } are both {int}.
>

sorry a typo:  it should be  

the method set and specific types of interface{ int; any } are both {int}.

-- 
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/24b410b6-879e-4f0b-9156-e6279f3bcb61n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?



On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote:

> So to be more specific, I think you're asking why this code works:
> https://gotipplay.golang.org/p/kuYzzx4EJY1
>
> Sorry, I made a mistake in interpreting the spec.  It also says:
>
> "The type set of the empty interface is the set of all types."
>
> Therefore, the type set of the intersection { int; any } is int - and 
> hence f[int] is allowed.
>
> But the set of specific types 
>  is empty:
>
> "An interface specification which contains type elements 
>  defines a (possibly 
> empty) set of *specific types*. Loosely speaking, these are the 
> types T that appear in the interface definition in terms of the form T, ~T, 
> or in unions of such terms."
>
> The type set and the set of specific types can be different. Examples are 
> given where one is empty and the other is non-empty:
>
> interface{ int; m() } // *[specific type]* int (but type set is empty 
> because int has no method m)
> interface{ int; any } // no specific types (intersection is empty) *[even 
> though the type set is not empty]*
>
> *Items in [italics/brackets] are my additions*
>

> The type set and the set of specific types can be different

This is true.

> interface{ int; any } // no specific types (intersection is empty) *[even 
though the type set is not empty]*

I don't think this is true. In my opinion, the method set of specific types 
of interface{ int; any } are both {int}.

-- 
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/48b67caf-19ae-4ffe-af4d-436268187ef2n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?



On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:

> No, the mistake is in your reading of the spec.  You are complaining about 
> this line:
>
> interface{ int; any } // no specific types (intersection is empty)
>
> The spec makes it clear that:
> 1. "any" is short for "interface {}"
> 2. "interface {}" has no *specific types*
>
>
I think your logic mistake here is that the operands of the union and 
intersection operations are type sets, instead of specific types.
 

> You are taking the intersection of the set of one type (int) with the 
> empty set, and therefore the result is the empty set.  Exactly as the 
> comment says.
>
> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>
>>> 1. interface { a;b } is intersection. The "Intersection" between two 
>>> sets means things which exist in both sets simultaneously.
>>> 2. interface { a|b } is union.  "Union" means a set of things which 
>>> which exist in set A *or* set B.
>>>
>>> Quoting from the spec:
>>> *"the predeclared type *any* is an alias for the empty interface." *
>>> *"interface{} // no specific types"*
>>> *"For an interface with type elements, 푆 is the intersection of the 
>>> specific types of its type elements."*
>>>
>>> Can you see now?
>>>
>>
>> The explanation is as what I think.
>> But what is your conclusion? Is it a mistake in spec?
>>
>

-- 
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/856006f6-0624-43e9-b3b8-a07a0d6744a6n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

I don't think your conclusion is right. Otherwise, the following code 
doesn't compile, but it does.

type C interface{ int; any }

func f[T C](x byte) T {
return T(x)
}

On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:

> No, the mistake is in your reading of the spec.  You are complaining about 
> this line:
>
> interface{ int; any } // no specific types (intersection is empty)
>
> The spec makes it clear that:
> 1. "any" is short for "interface {}"
> 2. "interface {}" has no *specific types*
> 3. "interface { int; any }" is an *intersection* of *specific types*
>
> You are taking the intersection of the set of one type (int) with the 
> empty set, and therefore the result is the empty set.  Exactly as the 
> comment says.
>
> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>
>>> 1. interface { a;b } is intersection. The "Intersection" between two 
>>> sets means things which exist in both sets simultaneously.
>>> 2. interface { a|b } is union.  "Union" means a set of things which 
>>> which exist in set A *or* set B.
>>>
>>> Quoting from the spec:
>>> *"the predeclared type *any* is an alias for the empty interface." *
>>> *"interface{} // no specific types"*
>>> *"For an interface with type elements, 푆 is the intersection of the 
>>> specific types of its type elements."*
>>>
>>> Can you see now?
>>>
>>
>> The explanation is as what I think.
>> But what is your conclusion? Is it a mistake in spec?
>>
>

-- 
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/e43a60ad-d812-418d-97e1-966fd3bcf61en%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?



On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:

> 1. interface { a;b } is intersection. The "Intersection" between two sets 
> means things which exist in both sets simultaneously.
> 2. interface { a|b } is union.  "Union" means a set of things which which 
> exist in set A *or* set B.
>
> Quoting from the spec:
> *"the predeclared type *any* is an alias for the empty interface." *
> *"interface{} // no specific types"*
> *"For an interface with type elements, 푆 is the intersection of the 
> specific types of its type elements."*
>
> Can you see now?
>

The explanation is as what I think.
But what is your conclusion? Is it a mistake in spec?

-- 
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/09ef1de2-de2d-42e0-ae2f-6188530c04den%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

2022-01-05 Thread tapi...@gmail.com



Should it be

interface{ int | any } // no specific types (intersection is empty)

instead
On Wednesday, January 5, 2022 at 11:20:16 PM UTC+8 tapi...@gmail.com wrote:

> https://tip.golang.org/ref/spec#Structure_of_interfaces
>
>interface{ int; any } // no specific types (intersection is empty)
>
>
> Why the constraint has no specific types. Doesn't it specify int?
>

-- 
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/09badb9a-0f63-4f49-9e07-be6266969f96n%40googlegroups.com.

[go-nuts] An mistake in tip spec?

2022-01-05 Thread tapi...@gmail.com

https://tip.golang.org/ref/spec#Structure_of_interfaces

   interface{ int; any } // no specific types (intersection is empty)


Why the constraint has no specific types. Doesn't it specify int?

-- 
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/3a8fab9a-5581-4789-a4ef-19f09c32c9b3n%40googlegroups.com.

Re: [go-nuts] some incorrect code in blog.

2021-11-26 Thread tapi...@gmail.com

Isn't the code should be:

*func CopyFile() {*
*   ...*
*   if err != nil {*
*  return*
*   }*

*   defer func() { err = src.Close() }()*
*   ...*
*}*

On Thursday, November 25, 2021 at 12:18:20 PM UTC+8 Ian Lance Taylor wrote:

> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang  wrote:
> >
> > There is some incorrect code in 
> https://go.dev/blog/defer-panic-and-recover blog.
> >
> > The original code is
> > func CopyFile() {
> > ...
> > if err != nil {
> > return
> > }
> > defer src.Close()
> > ...
> > }
> >
> > I think the correct code should be
> > func CopyFile() {
> > ...
> > defer src.Close()
> > if err != nil {
> > return
> > }
> > ...
> > }
> >
> > I do not know how to modify the go blog, can anyone help? Thank you.
>
> If you want to update the blog, send a patch for
> golang.org/x/website/_content/blog.
>
> (But please don't send this particular change. As Kurtis noted, the
> existing code is correct, and your change would not be correct.
> Thanks.)
>
> 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/e1da6a65-67e6-4ae3-943b-4f1124cafa20n%40googlegroups.com.

[go-nuts] Re: compile time error vs runtime crash for same array

2021-11-26 Thread tapi...@gmail.com

There is an issue for this: https://github.com/golang/go/issues/17378

On Sunday, November 14, 2021 at 1:46:29 AM UTC+8 arthurwil...@gmail.com 
wrote:

> On a 64bit Mac, this code:
>
> package main
>
> var X [^uint(0)>>14]byte
> func main() {
> }
>
> produces a compile time error:
> main.X: symbol too large (1125899906842623 bytes > 20 bytes)
>
> But this compiles and crashes at runtime. 
>
> package main
>
> func main() {
> var X [^uint(0) >> 14]byte
> _ = X
> }
>
> runtime: out of memory: cannot allocate 1125899906842624-byte block 
> (3997696 in use)
> fatal error: out of memory
>
> goroutine 1 [running]:
> runtime.throw({0x1061335, 0x11})
> /usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc42658 
> sp=0xc42628 pc=0x102b031
> runtime.(*mcache).allocLarge(0x100a734, 0x3, 0x11, 0x1)
> /usr/local/go/src/runtime/mcache.go:229 +0x22e fp=0xc426b8 
> sp=0xc42658 pc=0x101086e
> runtime.mallocgc(0x3, 0x1059300, 0x1)
> /usr/local/go/src/runtime/malloc.go:1082 +0x5c5 fp=0xc42738 
> sp=0xc426b8 pc=0x100a645
> runtime.newobject(0x1058a00)
> /usr/local/go/src/runtime/malloc.go:1228 +0x27 fp=0xc42760 
> sp=0xc42738 pc=0x100aa87
> main.main()
> /Users/billmorgan/git/tmp/main.go:5 +0x25 fp=0xc42780 
> sp=0xc42760 pc=0x1054c65
> runtime.main()
> /usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc427e0 
> sp=0xc42780 pc=0x102d6c7
> runtime.goexit()
> /usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc427e8 
> sp=0xc427e0 pc=0x1051fa1
>
>
> Why does the 2nd program succeed compilation of the same array that failed 
> compilation in the 1st program? 
>
> It was known ahead of time that the allocation would fail so I think the 
> 2nd program should have failed to compile too.
>
>
>
>
>

-- 
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/2b9e8c09-9e12-419d-bd68-df45508e8a9fn%40googlegroups.com.

[go-nuts] Re: compile time error vs runtime crash for same array

2021-11-26 Thread tapi...@gmail.com

It is 1 << 50 is the limit on heap. The following code doesn't compile:

package main

func main() {
var X [1 << 50]byte // type [1125899906842624]byte larger than address 
space
_ = X
}

But with 1 << 50 - 1, it compiles:

package main

func main() {
var X [1 << 50 - 1]byte // runtime: out of memory: cannot allocate 
1125899906842624-byte block (3997696 in use)
_ = X
}

It is weird that there are several different runtime error messages:


package main

func main() {
var X [1 << 46]byte // fatal error: runtime: out of memory
_ = X
}

package main

func main() {
var X [1 << 47]byte // runtime: out of memory: cannot allocate 
140737488355328-byte block (3997696 in use)\nfatal error: out of memory
_ = X
}

So it looks there are at least 3 thresholds are set in the code.

On Friday, November 26, 2021 at 12:00:20 PM UTC+8 arthurwil...@gmail.com 
wrote:

> On Saturday, November 13, 2021 at 12:48:41 PM UTC-6 seank...@gmail.com 
> wrote:
>
>> global variables are stored in there data section of the compiled binary, 
>> the linker imposes a 2GB size limit
>> the array in main can be allocated at runtime, and given enough memory, 
>> it could succeed
>>
>>
> Why does the linker impose a 2GB limit on .bss data but not heap memory? 
> Is there a limit on heap variables?  
>  
>
>>
>> On Saturday, November 13, 2021 at 5:46:29 PM UTC arthurwil...@gmail.com 
>> wrote:
>>
>>> On a 64bit Mac, this code:
>>>
>>> package main
>>>
>>> var X [^uint(0)>>14]byte
>>> func main() {
>>> }
>>>
>>> produces a compile time error:
>>> main.X: symbol too large (1125899906842623 bytes > 20 bytes)
>>>
>>> But this compiles and crashes at runtime. 
>>>
>>> package main
>>>
>>> func main() {
>>> var X [^uint(0) >> 14]byte
>>> _ = X
>>> }
>>>
>>> runtime: out of memory: cannot allocate 1125899906842624-byte block 
>>> (3997696 in use)
>>> fatal error: out of memory
>>>
>>> goroutine 1 [running]:
>>> runtime.throw({0x1061335, 0x11})
>>> /usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc42658 
>>> sp=0xc42628 pc=0x102b031
>>> runtime.(*mcache).allocLarge(0x100a734, 0x3, 0x11, 0x1)
>>> /usr/local/go/src/runtime/mcache.go:229 +0x22e fp=0xc426b8 
>>> sp=0xc42658 pc=0x101086e
>>> runtime.mallocgc(0x3, 0x1059300, 0x1)
>>> /usr/local/go/src/runtime/malloc.go:1082 +0x5c5 fp=0xc42738 
>>> sp=0xc426b8 pc=0x100a645
>>> runtime.newobject(0x1058a00)
>>> /usr/local/go/src/runtime/malloc.go:1228 +0x27 fp=0xc42760 
>>> sp=0xc42738 pc=0x100aa87
>>> main.main()
>>> /Users/billmorgan/git/tmp/main.go:5 +0x25 fp=0xc42780 
>>> sp=0xc42760 pc=0x1054c65
>>> runtime.main()
>>> /usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc427e0 
>>> sp=0xc42780 pc=0x102d6c7
>>> runtime.goexit()
>>> /usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc427e8 
>>> sp=0xc427e0 pc=0x1051fa1
>>>
>>>
>>> Why does the 2nd program succeed compilation of the same array that 
>>> failed compilation in the 1st program? 
>>>
>>> It was known ahead of time that the allocation would fail so I think the 
>>> 2nd program should have failed to compile too.
>>>
>>>
>>>
>>>
>>>

-- 
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/d3c56fbc-13dc-44f4-8022-af1833acfe2en%40googlegroups.com.

[go-nuts] Re: The runtime/slice_test.go shows most benchmarks become slower on tip (vs v1.17.3)

2021-11-22 Thread tapi...@gmail.com

fill an issue here: https://github.com/golang/go/issues/49744

On Tuesday, November 23, 2021 at 12:15:52 AM UTC+8 tapi...@gmail.com wrote:

> Slower about 20%. As least, on my machine, it looks so.
> As my machine is slow, I haven't use -count=10 and benchstat to make a 
> report.
>
>

-- 
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/4d366daa-3142-412d-9bcb-0be52985f1ffn%40googlegroups.com.

[go-nuts] The runtime/slice_test.go shows most benchmarks become slower on tip (vs v1.17.3)

2021-11-22 Thread tapi...@gmail.com

Slower about 20%. As least, on my machine, it looks so.
As my machine is slow, I haven't use -count=10 and benchstat to make a 
report.

-- 
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/bf5064d3-269f-4b5f-86d5-81148c77c1d2n%40googlegroups.com.

Re: [go-nuts] Re: About struct fields in type parameters

OK, I will try it several days later.

On Saturday, November 13, 2021 at 1:21:08 AM UTC+8 
axel.wa...@googlemail.com wrote:

> Yes, the doc is outdated. Since then, several changes have been made to 
> the design, to accomodate issues that either came up during the discussion 
> or where discovered after - one of the more significant is 
> https://github.com/golang/go/issues/45346, but there are others.
> That's why I said we should probably wait for the actual spec changes 
> before discussing it further, as there currently is no single authoritative 
> source for what will land in go 1.18.
>
> On Fri, Nov 12, 2021 at 6:18 PM tapi...@gmail.com  
> wrote:
>
>> The SliceConstraint example also doesn't work.
>>
>> Is the doc I mentioned outdated?
>>
>> On Saturday, November 13, 2021 at 1:13:13 AM UTC+8 tapi...@gmail.com 
>> wrote:
>>
>>> And this fails to compile, although the docs says it is valid:
>>>
>>> // sliceOrMap is a type constraint for a slice or a map.
>>> type sliceOrMap interface {
>>> []int | map[int]int
>>> }
>>>
>>> // Entry returns the i'th entry in a slice or the value of a map
>>> // at key i. This is valid as the result of the operator is always 
>>> int.
>>> func Entry[T sliceOrMap](c T, i int) int {
>>> // This is either a slice index operation or a map key lookup.
>>> // Either way, the index and result types are type int.
>>> return c[i] // invalid operation: cannot index c (variable of 
>>> type T constrained by sliceOrMap
>>> }
>>>
>>>
>>> On Saturday, November 13, 2021 at 1:10:30 AM UTC+8 tapi...@gmail.com 
>>> wrote:
>>>
>>>> The proposal design docs (
>>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
>>>>  
>>>> mentions:
>>>>
>>>> // structField is a type constraint whose type set consists of some
>>>> // struct types that all have a field named x.
>>>> type structField interface {
>>>> struct { a int; x int } |
>>>> struct { b int; x float64 } |
>>>> struct { c int; x uint64 }
>>>> }
>>>>
>>>> // This function is INVALID.
>>>> func IncrementX[T structField](p *T) {
>>>> v := p.x // INVALID: type of p.x is not the same for all types 
>>>> in set
>>>> v++
>>>> p.x = v
>>>> }
>>>>
>>>> However, it still fails to compile if all the types of the x fields are 
>>>> identical.
>>>>
>>>> type structField interface {
>>>> struct { a int; x int } |
>>>> struct { b int; x int } |
>>>> struct { c int; x int }
>>>> }
>>>>
>>>> func IncrementX[T structField](p *T) {
>>>> v := p.x // p.x undefined (type *T has no field or method x)
>>>> v++
>>>> p.x = v  // p.x undefined (type *T has no field or method x)
>>>> }
>>>>
>>>>
>>>>
>>>> -- 
>> 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/785df174-2e12-49bc-a3af-f143a89cd831n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/785df174-2e12-49bc-a3af-f143a89cd831n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/56b07f60-9928-4e21-b2f7-5358c05a9306n%40googlegroups.com.

Re: [go-nuts] How the scopes of type parameters are defined?



On Friday, November 12, 2021 at 6:07:11 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> And FWIW, just to illustrate the expected complexity: We also want these 
> two declarations to mean the same:
> func A[T A]()
> func B[T interface{ A }]()
> So the rules also need to accommodate that. It gets only more complicated 
> from there.
>


Are the followings also intended?

func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
return T // T (type) is not an expression
}

func Bar[T any](x T) T {
var T = x // T redeclared in this block
return T
}
 

>
> On Fri, Nov 12, 2021 at 11:03 AM Axel Wagner  
> wrote:
>
>>
>>
>> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com  
>> wrote:
>>
>>>
>>>
>>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 
>>> axel.wa...@googlemail.com wrote:
>>>
>>>> I suspect this issue is hard/impossible to avoid, because it must be 
>>>> possible to self- and mutually reference type-parameters, in a way that 
>>>> it's not for normal parameters, to allow to write something like
>>>>
>>>> type Equaler[T any] interface {
>>>> Equal(T) bool
>>>> }
>>>> func Eq[T Equaler[T]](a, b T) bool {
>>>> return a.Equal(b)
>>>> }
>>>>
>>>
>>> I don't see the same problem here. "T" and "Equaler" are two different 
>>> identifiers.
>>>
>>
>> But T and T are not.
>>
>> The point I was making is that type-parameters must inherently be scoped 
>> in a way that makes them visible in the type-list itself, to make writing 
>> code like this possible. This isn't necessary for regular parameters and 
>> it's what makes type-parameter lists special.
>>
>> I *also* said that it's probably possible to devise rules which would 
>> make this possible, while allowing the example you wrote, just that those 
>> rules would have to be complicated.
>>  
>>
>>>  
>>>
>>>>
>>>> or basically any use-case for constraint-type inference.
>>>>
>>>> Even if we *could* allow it consistently, the rules for doing that 
>>>> would likely be pretty complex. Better to take the relatively minor hit of 
>>>> disallowing this overloading (you can always use different names for the 
>>>> type-parameters, if they conflict with the constraint you want to use) 
>>>> than 
>>>> to take the hit of complex scoping rules with lots of exceptions.
>>>>
>>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com  
>>>> wrote:
>>>>
>>>>> I expect the following code compilers okay, but it doesn't.
>>>>> It looks All the three "I" in the Bar function declaration are
>>>>> viewed as the type parameter, whereas the second one is
>>>>> expected as the constraint I (at least by me).
>>>>>
>>>>> package main
>>>>>
>>>>> type I interface { M() }
>>>>>
>>>>> func Foo(i I) {
>>>>>   i.M()
>>>>> }
>>>>>
>>>>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>>>>   i.M()
>>>>> }
>>>>>
>>>>> func main() {}
>>>>>
>>>>> -- 
>>>>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/golang-nuts/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/02e92a27-93a3-41ab-9955-52898d494540n%40googlegroups.com.

Re: [go-nuts] How the scopes of type parameters are defined?

Are the followings also intended?

func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
return T // T (type) is not an expression
}

func Bar[T any](x T) T {
var T = x // T redeclared in this block
return T
}

On Friday, November 12, 2021 at 6:07:11 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> And FWIW, just to illustrate the expected complexity: We also want these 
> two declarations to mean the same:
> func A[T A]()
> func B[T interface{ A }]()
> So the rules also need to accommodate that. It gets only more complicated 
> from there.
>
> On Fri, Nov 12, 2021 at 11:03 AM Axel Wagner  
> wrote:
>
>>
>>
>> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com  
>> wrote:
>>
>>>
>>>
>>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 
>>> axel.wa...@googlemail.com wrote:
>>>
>>>> I suspect this issue is hard/impossible to avoid, because it must be 
>>>> possible to self- and mutually reference type-parameters, in a way that 
>>>> it's not for normal parameters, to allow to write something like
>>>>
>>>> type Equaler[T any] interface {
>>>> Equal(T) bool
>>>> }
>>>> func Eq[T Equaler[T]](a, b T) bool {
>>>> return a.Equal(b)
>>>> }
>>>>
>>>
>>> I don't see the same problem here. "T" and "Equaler" are two different 
>>> identifiers.
>>>
>>
>> But T and T are not.
>>
>> The point I was making is that type-parameters must inherently be scoped 
>> in a way that makes them visible in the type-list itself, to make writing 
>> code like this possible. This isn't necessary for regular parameters and 
>> it's what makes type-parameter lists special.
>>
>> I *also* said that it's probably possible to devise rules which would 
>> make this possible, while allowing the example you wrote, just that those 
>> rules would have to be complicated.
>>  
>>
>>>  
>>>
>>>>
>>>> or basically any use-case for constraint-type inference.
>>>>
>>>> Even if we *could* allow it consistently, the rules for doing that 
>>>> would likely be pretty complex. Better to take the relatively minor hit of 
>>>> disallowing this overloading (you can always use different names for the 
>>>> type-parameters, if they conflict with the constraint you want to use) 
>>>> than 
>>>> to take the hit of complex scoping rules with lots of exceptions.
>>>>
>>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com  
>>>> wrote:
>>>>
>>>>> I expect the following code compilers okay, but it doesn't.
>>>>> It looks All the three "I" in the Bar function declaration are
>>>>> viewed as the type parameter, whereas the second one is
>>>>> expected as the constraint I (at least by me).
>>>>>
>>>>> package main
>>>>>
>>>>> type I interface { M() }
>>>>>
>>>>> func Foo(i I) {
>>>>>   i.M()
>>>>> }
>>>>>
>>>>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>>>>   i.M()
>>>>> }
>>>>>
>>>>> func main() {}
>>>>>
>>>>> -- 
>>>>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/golang-nuts/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/ec05df1e-4979-42ad-b5dc-5d3915355c57n%40googlegroups.com.

Re: [go-nuts] How the scopes of type parameters are defined?



On Friday, November 12, 2021 at 6:04:01 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com  
> wrote:
>
>>
>>
>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 
>> axel.wa...@googlemail.com wrote:
>>
>>> I suspect this issue is hard/impossible to avoid, because it must be 
>>> possible to self- and mutually reference type-parameters, in a way that 
>>> it's not for normal parameters, to allow to write something like
>>>
>>> type Equaler[T any] interface {
>>> Equal(T) bool
>>> }
>>> func Eq[T Equaler[T]](a, b T) bool {
>>> return a.Equal(b)
>>> }
>>>
>>
>> I don't see the same problem here. "T" and "Equaler" are two different 
>> identifiers.
>>
>
> But T and T are not.
>
> The point I was making is that type-parameters must inherently be scoped 
> in a way that makes them visible in the type-list itself, to make writing 
> code like this possible. This isn't necessary for regular parameters and 
> it's what makes type-parameter lists special.
>
> I *also* said that it's probably possible to devise rules which would make 
> this possible, while allowing the example you wrote, just that those rules 
> would have to be complicated.
>

How much complicated? Is it similar to 

func foo(int int) {}
 

>  
>
>>  
>>
>>>
>>> or basically any use-case for constraint-type inference.
>>>
>>> Even if we *could* allow it consistently, the rules for doing that would 
>>> likely be pretty complex. Better to take the relatively minor hit of 
>>> disallowing this overloading (you can always use different names for the 
>>> type-parameters, if they conflict with the constraint you want to use) than 
>>> to take the hit of complex scoping rules with lots of exceptions.
>>>
>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com  
>>> wrote:
>>>
>>>> I expect the following code compilers okay, but it doesn't.
>>>> It looks All the three "I" in the Bar function declaration are
>>>> viewed as the type parameter, whereas the second one is
>>>> expected as the constraint I (at least by me).
>>>>
>>>> package main
>>>>
>>>> type I interface { M() }
>>>>
>>>> func Foo(i I) {
>>>>   i.M()
>>>> }
>>>>
>>>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>>>   i.M()
>>>> }
>>>>
>>>> func main() {}
>>>>
>>>> -- 
>>>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/3d4fc243-f3dc-4071-b6ac-8c5462061e3en%40googlegroups.com.

Re: [go-nuts] Re: What is the problem of the generic use?

fine? It should not.

On Friday, November 12, 2021 at 3:04:20 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> Please ask an actual question, don't just post some code.
> FTR the code you posted (with the substitution you suggest) compiles and 
> runs fine using gotip.
>
> On Fri, Nov 12, 2021 at 6:18 AM tapi...@gmail.com  
> wrote:
>
>> sorry, a mistake, "int" -> "[]byte".
>>
>> On Friday, November 12, 2021 at 1:08:50 PM UTC+8 tapi...@gmail.com wrote:
>>
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> )
>>>
>>> type byteview interface{string | int}
>>>
>>> type ByteView[T byteview] struct {v [0]T}
>>>
>>> func (bv ByteView[T]) Write(v T) (int, error) {
>>> return 0, nil
>>> }
>>>
>>> type Writer[T byteview] interface {
>>> Write(bs T)(int, error)
>>> }
>>>
>>> type ioWriter = Writer[[]byte] // []byte does not satisfy comparable
>>>
>>> func main() {
>>> fmt.Println("Hello, playground")
>>> }
>>>
>> -- 
>> 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/5342cd82-a51f-4d9d-af79-d7a5e2a1b663n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/5342cd82-a51f-4d9d-af79-d7a5e2a1b663n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/087f84b6-7866-4e36-8bc9-a85170a26e7en%40googlegroups.com.

[go-nuts] Re: About struct fields in type parameters

The SliceConstraint example also doesn't work.

Is the doc I mentioned outdated?

On Saturday, November 13, 2021 at 1:13:13 AM UTC+8 tapi...@gmail.com wrote:

> And this fails to compile, although the docs says it is valid:
>
> // sliceOrMap is a type constraint for a slice or a map.
> type sliceOrMap interface {
> []int | map[int]int
> }
>
> // Entry returns the i'th entry in a slice or the value of a map
> // at key i. This is valid as the result of the operator is always int.
> func Entry[T sliceOrMap](c T, i int) int {
> // This is either a slice index operation or a map key lookup.
> // Either way, the index and result types are type int.
> return c[i] // invalid operation: cannot index c (variable of type 
> T constrained by sliceOrMap
> }
>
>
> On Saturday, November 13, 2021 at 1:10:30 AM UTC+8 tapi...@gmail.com 
> wrote:
>
>> The proposal design docs (
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
>>  
>> mentions:
>>
>> // structField is a type constraint whose type set consists of some
>> // struct types that all have a field named x.
>> type structField interface {
>> struct { a int; x int } |
>> struct { b int; x float64 } |
>> struct { c int; x uint64 }
>> }
>>
>> // This function is INVALID.
>> func IncrementX[T structField](p *T) {
>> v := p.x // INVALID: type of p.x is not the same for all types in 
>> set
>> v++
>> p.x = v
>> }
>>
>> However, it still fails to compile if all the types of the x fields are 
>> identical.
>>
>> type structField interface {
>> struct { a int; x int } |
>> struct { b int; x int } |
>> struct { c int; x int }
>> }
>>
>> func IncrementX[T structField](p *T) {
>> v := p.x // p.x undefined (type *T has no field or method x)
>> v++
>> p.x = v  // p.x undefined (type *T has no field or method x)
>> }
>>
>>
>>
>>

-- 
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/785df174-2e12-49bc-a3af-f143a89cd831n%40googlegroups.com.

[go-nuts] Re: About struct fields in type parameters

And this fails to compile, although the docs says it is valid:

// sliceOrMap is a type constraint for a slice or a map.
type sliceOrMap interface {
[]int | map[int]int
}

// Entry returns the i'th entry in a slice or the value of a map
// at key i. This is valid as the result of the operator is always int.
func Entry[T sliceOrMap](c T, i int) int {
// This is either a slice index operation or a map key lookup.
// Either way, the index and result types are type int.
return c[i] // invalid operation: cannot index c (variable of type 
T constrained by sliceOrMap
}

On Saturday, November 13, 2021 at 1:10:30 AM UTC+8 tapi...@gmail.com wrote:

> The proposal design docs (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
>  
> mentions:
>
> // structField is a type constraint whose type set consists of some
> // struct types that all have a field named x.
> type structField interface {
> struct { a int; x int } |
> struct { b int; x float64 } |
> struct { c int; x uint64 }
> }
>
> // This function is INVALID.
> func IncrementX[T structField](p *T) {
> v := p.x // INVALID: type of p.x is not the same for all types in 
> set
> v++
> p.x = v
> }
>
> However, it still fails to compile if all the types of the x fields are 
> identical.
>
> type structField interface {
> struct { a int; x int } |
> struct { b int; x int } |
> struct { c int; x int }
> }
>
> func IncrementX[T structField](p *T) {
> v := p.x // p.x undefined (type *T has no field or method x)
> v++
> p.x = v  // p.x undefined (type *T has no field or method x)
> }
>
>
>
>

-- 
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/7f2e88e1-5a50-4aae-9e72-94d6b43f5f16n%40googlegroups.com.

[go-nuts] About struct fields in type parameters

The proposal design docs 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
 
mentions:

// structField is a type constraint whose type set consists of some
// struct types that all have a field named x.
type structField interface {
struct { a int; x int } |
struct { b int; x float64 } |
struct { c int; x uint64 }
}

// This function is INVALID.
func IncrementX[T structField](p *T) {
v := p.x // INVALID: type of p.x is not the same for all types in 
set
v++
p.x = v
}

However, it still fails to compile if all the types of the x fields are 
identical.

type structField interface {
struct { a int; x int } |
struct { b int; x int } |
struct { c int; x int }
}

func IncrementX[T structField](p *T) {
v := p.x // p.x undefined (type *T has no field or method x)
v++
p.x = v  // p.x undefined (type *T has no field or method x)
}



-- 
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/451c441a-d4c1-48e5-aa1a-01118bd32f1en%40googlegroups.com.

Re: [go-nuts] Is this a known problem?

This one doesn't compile either.
So the range operation doesn't support values of parameter types?

type MyByte byte

func Bar[T []byte|[]MyByte](s T) {
for range s {} // cannot range over s (variable of type T constrained 
by []byte|[]MyByte) (type set has no single underlying 
} 

On Friday, November 12, 2021 at 11:40:53 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com  
> wrote:
>
>> On Friday, November 12, 2021 at 11:10:17 PM UTC+8 
>> axel.wa...@googlemail.com wrote:
>>
>>> `range s` works differently for string and []byte. In the former case it 
>>> iterates over utf8-encoded unicode codepoints, in the latter it iterates 
>>> over bytes.
>>>
>>
>> It is true, but why it matters here?
>>
>
> Because it makes `range` different operations for the purposes of 
> determining the allowed operations on a type-parameter.
>  
>
>>  
>>
>>>
>>> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>>
>>>> func Bar[T []byte|string](s T) bool {
>>>> for _, v := range s { // cannot range over s (variable of type T 
>>>> constrained by []byte|string) (T has no structural type)
>>>> if v > 100 {
>>>> return true
>>>> }
>>>> }
>>>> return false
>>>> }
>>>>
>>>> The message is quite confusing.
>>>>
>>>> -- 
>>>> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> 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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/42054eee-a9df-40d1-b148-4e5ead89ee0cn%40googlegroups.com.

Re: [go-nuts] Is this a known problem?



On Friday, November 12, 2021 at 11:10:17 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> `range s` works differently for string and []byte. In the former case it 
> iterates over utf8-encoded unicode codepoints, in the latter it iterates 
> over bytes.
>

It is true, but why it matters here?
 

>
> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com  
> wrote:
>
>>
>> func Bar[T []byte|string](s T) bool {
>> for _, v := range s { // cannot range over s (variable of type T 
>> constrained by []byte|string) (T has no structural type)
>> if v > 100 {
>> return true
>> }
>> }
>> return false
>> }
>>
>> The message is quite confusing.
>>
>> -- 
>> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com.

[go-nuts] Is this a known problem?


func Bar[T []byte|string](s T) bool {
for _, v := range s { // cannot range over s (variable of type T 
constrained by []byte|string) (T has no structural type)
if v > 100 {
return true
}
}
return false
}

The message is quite confusing.

-- 
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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com.

Re: [go-nuts] How the scopes of type parameters are defined?



On Friday, November 12, 2021 at 5:33:19 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> I suspect this issue is hard/impossible to avoid, because it must be 
> possible to self- and mutually reference type-parameters, in a way that 
> it's not for normal parameters, to allow to write something like
>
> type Equaler[T any] interface {
> Equal(T) bool
> }
> func Eq[T Equaler[T]](a, b T) bool {
> return a.Equal(b)
> }
>

I don't see the same problem here. "T" and "Equaler" are two different 
identifiers.
 

>
> or basically any use-case for constraint-type inference.
>
> Even if we *could* allow it consistently, the rules for doing that would 
> likely be pretty complex. Better to take the relatively minor hit of 
> disallowing this overloading (you can always use different names for the 
> type-parameters, if they conflict with the constraint you want to use) than 
> to take the hit of complex scoping rules with lots of exceptions.
>
> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com  
> wrote:
>
>> I expect the following code compilers okay, but it doesn't.
>> It looks All the three "I" in the Bar function declaration are
>> viewed as the type parameter, whereas the second one is
>> expected as the constraint I (at least by me).
>>
>> package main
>>
>> type I interface { M() }
>>
>> func Foo(i I) {
>>   i.M()
>> }
>>
>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>   i.M()
>> }
>>
>> func main() {}
>>
>> -- 
>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com.

[go-nuts] How the scopes of type parameters are defined?

I expect the following code compilers okay, but it doesn't.
It looks All the three "I" in the Bar function declaration are
viewed as the type parameter, whereas the second one is
expected as the constraint I (at least by me).

package main

type I interface { M() }

func Foo(i I) {
  i.M()
}

func Bar[I I](i I) { // cannot use a type parameter as constraint
  i.M()
}

func main() {}

-- 
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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com.

[go-nuts] Re: What is the problem of the generic use?

2021-11-11 Thread tapi...@gmail.com

sorry, a mistake, "int" -> "[]byte".

On Friday, November 12, 2021 at 1:08:50 PM UTC+8 tapi...@gmail.com wrote:

>
> package main
>
> import (
> "fmt"
> )
>
> type byteview interface{string | int}
>
> type ByteView[T byteview] struct {v [0]T}
>
> func (bv ByteView[T]) Write(v T) (int, error) {
> return 0, nil
> }
>
> type Writer[T byteview] interface {
> Write(bs T)(int, error)
> }
>
> type ioWriter = Writer[[]byte] // []byte does not satisfy comparable
>
> func main() {
> fmt.Println("Hello, playground")
> }
>

-- 
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/5342cd82-a51f-4d9d-af79-d7a5e2a1b663n%40googlegroups.com.

[go-nuts] What is the problem of the generic use?

2021-11-11 Thread tapi...@gmail.com


package main

import (
"fmt"
)

type byteview interface{string | int}

type ByteView[T byteview] struct {v [0]T}

func (bv ByteView[T]) Write(v T) (int, error) {
return 0, nil
}

type Writer[T byteview] interface {
Write(bs T)(int, error)
}

type ioWriter = Writer[[]byte] // []byte does not satisfy comparable

func main() {
fmt.Println("Hello, playground")
}

-- 
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/c31d8440-b164-4d6e-b8d2-76a3eaaa7e5fn%40googlegroups.com.

[go-nuts] Re: Small number change will affect benchmark results

2021-10-30 Thread tapi...@gmail.com

This is fixed in https://go-review.googlesource.com/c/go/+/359477
The benchmarks become much less weird. https://play.golang.org/p/leXp-8MB6gi

On Wednesday, August 18, 2021 at 11:35:05 PM UTC-4 tapi...@gmail.com wrote:

> More specifically, the last parameter (needzero) of mallocgc is not passed 
> down to c.nextFree, which causes the memclrNoHeapPointers function is 
> called twice in makeslicecopy if the slice size <= 32768.
>
> On Wednesday, August 18, 2021 at 11:06:53 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>> Spent some time on investigating this problem. It is confirmed that, when 
>> N == 16384, the memclrNoHeapPointers function is called twice in the 
>> Insert2 function. That means the "make+copy` optimization introduced in Go 
>> 1.15 will perform worse than the normal route under such situation.
>>
>> On Wednesday, July 28, 2021 at 10:43:38 AM UTC-4 tapi...@gmail.com wrote:
>>
>>>
>>> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp
>>>
>>> When N == 16384, the benchmark result:
>>>
>>> Benchmark_Insert-4  134622  8032 ns/op   32768 
>>> B/op   1 allocs/op
>>> Benchmark_Insert2-4 132049  8201 ns/op   32768 
>>> B/op   1 allocs/op
>>>
>>> When N == 16385, the benchmark result:
>>>
>>> Benchmark_Insert-4  118677  9374 ns/op   40960 
>>> B/op   1 allocs/op
>>> Benchmark_Insert2-4 136845  7744 ns/op   40960 
>>> B/op   1 allocs/op
>>>
>>

-- 
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/f06bf32c-77f4-4822-b111-f14e1aa0f05fn%40googlegroups.com.

[go-nuts] It looks this is not a goal to make builtin generics be able to be defined/used by the custom generic rules?

2021-10-09 Thread tapi...@gmail.com

  
Ian Lance Taylor mentioned that "That is true: that was not a goal":
https://github.com/golang/go/discussions/47330#discussioncomment-1451011

Was? Does it mean it is now?

-- 
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/5200f51a-bc1c-4ec9-8ec2-577655415fc1n%40googlegroups.com.

[go-nuts] Re: Named results allocated on stack instead of register?

2021-09-20 Thread tapi...@gmail.com

It looks this is related to code inlining.
If we add //go:noinline directive for the two functions,
then they have no performance difference.

On Monday, September 20, 2021 at 12:39:51 PM UTC-4 tapi...@gmail.com wrote:

> Sometimes, a function with named results is slower.
> For example: https://play.golang.org/p/wvWkfSRqDLr
>
> The generated directives are almost the same for the two
> functions with a named and unnamed result, except one difference.
> For the function with the named result, the result represents as "".ret
> in the generated directive, but for the function with the unnamed result,
> the result represents as "".~r1 in the generated directive.
>
> Does "".ret means the result is allocated on stack? 
>
>
>

-- 
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/f962870a-17a4-4691-8f8d-282d27373018n%40googlegroups.com.

[go-nuts] Named results allocated on stack instead of register?

2021-09-20 Thread tapi...@gmail.com

Sometimes, a function with named results is slower.
For example: https://play.golang.org/p/wvWkfSRqDLr

The generated directives are almost the same for the two
functions with a named and unnamed result, except one difference.
For the function with the named result, the result represents as "".ret
in the generated directive, but for the function with the unnamed result,
the result represents as "".~r1 in the generated directive.

Does "".ret means the result is allocated on stack? 


-- 
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/4a9bb90a-02d2-42c9-836c-38b411a8bc7cn%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

2021-09-05 Thread tapi...@gmail.com



On Sunday, September 5, 2021 at 2:26:23 AM UTC-4 axel.wa...@googlemail.com 
wrote:

> On Sun, Sep 5, 2021 at 7:02 AM tapi...@gmail.com  
> wrote:
>
>>
>>
>> On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote:
>>
>>> On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>> Why? That is an undocumented implementation detail. Furthermore, the 
>>>>> length of "x1" and "x2" at the time when they are appended to, in 
>>>>> combination with the value being appended, are reasonable predictors of 
>>>>> the 
>>>>> capacity of the new slice. It is up to you to prove that a different 
>>>>> heuristic performs better. 
>>>>>
>>>>
>>>> Are there some evidences to prove the current algorithm is better?
>>>>
>>>
> There are two ways in which the current algorithm may be "better" than the 
> alternative:
> • If the alternative is to always double, then the current algorithm saves 
> significant memory for large slices, which is better.
> • The alternative is to use 1.25 starting at a different threshold (you 
> can't *always* use 1.25, as that would fail for n<4). Finding evidence of 
> whether this is better is easy: change the code, run the benchmarks, see 
> how they change.
>  
>
>> It is your responsibility to show that a different heuristic (not 
>>> "algorithm"). is better. 
>>>
>>
>> I have shown some examples above, which outputs will be more in line with 
>> exception
>> if the heuristic will only depends on the sum length of the two arguments.
>>
>
> Okay. Your expectation is wrong. What's the problem with that?
>
> I have *never* cared about how much `append` grows a slice. Not even 
> once. Even if I had cared to make a prediction and that prediction turned 
> out wrong, it would never have mattered. Why do you think it does?
>

No expectations are wrong, or right. They are like personal tastes.
Personally, I think monotonically increasing is good taste.
 

>  
>
>>
>> Clarification: I don't think the exponential growth algorithm is bad.
>> I just think it should make the capacities increase monotonically.
>>  
>>
>>>
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>> -- 
>>
> 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/8892db72-1392-4ee3-b336-5c64c6ef7f1cn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/8892db72-1392-4ee3-b336-5c64c6ef7f1cn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/88b20816-3c6b-4830-af53-ed3b988d81e0n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?



On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com  
> wrote:
>
>> Why? That is an undocumented implementation detail. Furthermore, the 
>>> length of "x1" and "x2" at the time when they are appended to, in 
>>> combination with the value being appended, are reasonable predictors of the 
>>> capacity of the new slice. It is up to you to prove that a different 
>>> heuristic performs better. 
>>>
>>
>> Are there some evidences to prove the current algorithm is better?
>>
>
> It is your responsibility to show that a different heuristic (not 
> "algorithm"). is better. 
>

I have shown some examples above, which outputs will be more in line with 
exception
if the heuristic will only depends on the sum length of the two arguments.

Clarification: I don't think the exponential growth algorithm is bad.
I just think it should make the capacities increase monotonically.
 

>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/8892db72-1392-4ee3-b336-5c64c6ef7f1cn%40googlegroups.com.

[go-nuts] Re: Function to escape and unscape string

This is a known problem: https://github.com/golang/go/issues/8618
I looks the root cause is reflect.TypeOf and ValueOf make the values 
referenced by the arguments escape, though often this is over-cautious.

On Sunday, August 29, 2021 at 3:02:42 PM UTC-4 nadashin wrote:

> fmt.Printf has a format specifier, %q that escapes string with Go
> syntax and add quotes around the string. ( %#v also does it)
>
> But it doesn't have one that unescapes a string.
>
> I couldn't find any stdlib function that escape and unescape a string
> following Go syntax. (and doesn't add quotes around the string)
>
>

-- 
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/0b860574-4075-43c1-a419-b1192ba4c3b0n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?



On Sunday, September 5, 2021 at 12:12:46 AM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 8:57 PM tapi...@gmail.com  
> wrote:
>
>> On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote:
>>
>>> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>> The problem of the current algorithm is it is not monotonically 
>>>> increasing:
>>>>
>>>
>>> Please explain why that is a problem. Also, I think you are 
>>> misusing "monotonically increasing". The behavior up to length 1024 is not 
>>> "monotonically increasing". It is exponential growth.
>>>
>>
>> I mean the whole length range. Why would you seect [0, 1023]?
>> I never deny it is exponential growth.
>>
>
> Okay, I agree that technically your use of "monotonically increasing" does 
> not preclude exponential growth. However, your contrasting the behavior 
> around the pivot point of 1024 implies that exponential growth is excluded 
> since the growth is exponential on each side of the pivot point and you 
> stated it was "monotonically increasing" on one side but not the other. 
>

My opinions include:
1. there should not be a slip in the whole number range.
2. the increasing should totally depend on the sum length of the two 
arguments.
 

>  
>
>> x1 := make([]int, 897)
>>>> x2 := make([]int, 1024)
>>>> y := make([]int, 100)
>>>> println(cap(append(x1, y...))) // 2048
>>>> println(cap(append(x2, y...))) // 1280
>>>>
>>>> And it is not symmetrical:
>>>>
>>>
>>> Again, please explain why this is a problem.
>>>
>>
>> When I merge two slices, I expect the argument orders are not important.
>>
>
> Why? That is an undocumented implementation detail. Furthermore, the 
> length of "x1" and "x2" at the time when they are appended to, in 
> combination with the value being appended, are reasonable predictors of the 
> capacity of the new slice. It is up to you to prove that a different 
> heuristic performs better. 
>

Are there some evidences to prove the current algorithm is better?
 

>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/1b4a000d-a71b-4d89-b509-9201b81ba547n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?



On Sunday, September 5, 2021 at 12:16:48 AM UTC-4 kortschak wrote:

> This is what you're describing, right? 
> https://play.golang.org/p/RJbEkmFsPKM 
>
> The code that does this is here 
>
> https://github.com/golang/go/blob/9133245be7365c23fcd60e3bb60ebb614970cdab/src/runtime/slice.go#L183-L242
>  
> . Note that there are cap adjustments to optimise block sizes and 
> alignments. This explains why we see what we do. 
>

Yes, this is the current algorithm. I don't think aligning to a nearby 
memory block size is a problem.
Personally, I think the slice grow algorithm should not depend on slice 
capacities.
 

>
> On Sat, 2021-09-04 at 20:57 -0700, tapi...@gmail.com wrote: 
> > 
> > 
> > On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader 
> > wrote: 
> > > On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com  > > > wrote: 
> > > > The problem of the current algorithm is it is not monotonically 
> > > > increasing: 
> > > > 
> > > 
> > > Please explain why that is a problem. Also, I think you are 
> > > misusing "monotonically increasing". The behavior up to length 1024 
> > > is not "monotonically increasing". It is exponential growth. 
> > > 
> > 
> > I mean the whole length range. Why would you seect [0, 1023]? 
> > I never deny it is exponential growth. 
> > 
> > > 
> > > > x1 := make([]int, 897) 
> > > > x2 := make([]int, 1024) 
> > > > y := make([]int, 100) 
> > > > println(cap(append(x1, y...))) // 2048 
> > > > println(cap(append(x2, y...))) // 1280 
> > > > 
> > > > And it is not symmetrical: 
> > > > 
> > > 
> > > Again, please explain why this is a problem. 
> > > 
> > 
> > When I merge two slices, I expect the argument orders are not 
> > important. 
> > 
> > > 
> > > > x := make([]int, 98) 
> > > > y := make([]int, 666) 
> > > > println(cap(append(x, y...))) // 768 
> > > > println(cap(append(y, x...))) // 1360 
> > > > 
> > > > And it depends on the capacity of the first argument, 
> > > > which is some logical but often not for many cases: 
> > > > 
> > > > x := make([]byte, 100, 500) 
> > > > y := make([]byte, 500) 
> > > > println(cap(append(x, y...))) // 1024 
> > > > println(cap(append(x[:len(x):len(x)], y...))) // 640 
> > > > 
> > > > On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote: 
> > > > > Hey Guys, 
> > > > > 
> > > > > We know slices grow by doubling until size 1024, the capacity 
> > > > > will grow at 25%. The question that I had was why after 1024 
> > > > > elements? Why didn't the developers chose another number like 
> > > > > 2048 or other numbers? 
> > > > > 
> > > > > Thanks, 
> > > > > Milad 
> > > > -- 
> > > > 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/45753fb8-429b-4407-9728-411b75a98484n%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/ca26dfa4-03d0-425f-a6b4-2b80e5f7e65an%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?



On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com  
> wrote:
>
>> The problem of the current algorithm is it is not monotonically 
>> increasing:
>>
>
> Please explain why that is a problem. Also, I think you are 
> misusing "monotonically increasing". The behavior up to length 1024 is not 
> "monotonically increasing". It is exponential growth.
>

I mean the whole length range. Why would you seect [0, 1023]?
I never deny it is exponential growth.
 

>  
>
>> x1 := make([]int, 897)
>> x2 := make([]int, 1024)
>> y := make([]int, 100)
>> println(cap(append(x1, y...))) // 2048
>> println(cap(append(x2, y...))) // 1280
>>
>> And it is not symmetrical:
>>
>
> Again, please explain why this is a problem.
>

When I merge two slices, I expect the argument orders are not important.
 

>  
>
>> x := make([]int, 98)
>> y := make([]int, 666)
>> println(cap(append(x, y...))) // 768
>> println(cap(append(y, x...))) // 1360
>>
>> And it depends on the capacity of the first argument,
>> which is some logical but often not for many cases:
>>
>> x := make([]byte, 100, 500)
>> y := make([]byte, 500)
>> println(cap(append(x, y...))) // 1024
>> println(cap(append(x[:len(x):len(x)], y...))) // 640
>>
>> On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote:
>>
>>> Hey Guys,
>>>
>>> We know slices grow by doubling until size 1024, the capacity will grow 
>>> at 25%. The question that I had was why after 1024 elements? Why didn't the 
>>> developers chose another number like 2048 or other numbers?
>>>
>>> Thanks,
>>> Milad
>>>
>> -- 
>>
> 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/45753fb8-429b-4407-9728-411b75a98484n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/45753fb8-429b-4407-9728-411b75a98484n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/529b4ee9-14a8-4145-853d-1ebdb9e9fa67n%40googlegroups.com.

[go-nuts] Re: slices grow at 25% after 1024 but why 1024?

The problem of the current algorithm is it is not monotonically increasing:

x1 := make([]int, 897)
x2 := make([]int, 1024)
y := make([]int, 100)
println(cap(append(x1, y...))) // 2048
println(cap(append(x2, y...))) // 1280

And it is not symmetrical:

x := make([]int, 98)
y := make([]int, 666)
println(cap(append(x, y...))) // 768
println(cap(append(y, x...))) // 1360

And it depends on the capacity of the first argument,
which is some logical but often not for many cases:

x := make([]byte, 100, 500)
y := make([]byte, 500)
println(cap(append(x, y...))) // 1024
println(cap(append(x[:len(x):len(x)], y...))) // 640

On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote:

> Hey Guys,
>
> We know slices grow by doubling until size 1024, the capacity will grow at 
> 25%. The question that I had was why after 1024 elements? Why didn't the 
> developers chose another number like 2048 or other numbers?
>
> Thanks,
> Milad
>

-- 
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/45753fb8-429b-4407-9728-411b75a98484n%40googlegroups.com.

[go-nuts] Re: Small number change will affect benchmark results

2021-08-18 Thread tapi...@gmail.com

The PR: https://github.com/golang/go/pull/47804

On Wednesday, August 18, 2021 at 11:35:05 PM UTC-4 tapi...@gmail.com wrote:

> More specifically, the last parameter (needzero) of mallocgc is not passed 
> down to c.nextFree, which causes the memclrNoHeapPointers function is 
> called twice in makeslicecopy if the slice size <= 32768.
>
> On Wednesday, August 18, 2021 at 11:06:53 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>> Spent some time on investigating this problem. It is confirmed that, when 
>> N == 16384, the memclrNoHeapPointers function is called twice in the 
>> Insert2 function. That means the "make+copy` optimization introduced in Go 
>> 1.15 will perform worse than the normal route under such situation.
>>
>> On Wednesday, July 28, 2021 at 10:43:38 AM UTC-4 tapi...@gmail.com wrote:
>>
>>>
>>> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp
>>>
>>> When N == 16384, the benchmark result:
>>>
>>> Benchmark_Insert-4  134622  8032 ns/op   32768 
>>> B/op   1 allocs/op
>>> Benchmark_Insert2-4 132049  8201 ns/op   32768 
>>> B/op   1 allocs/op
>>>
>>> When N == 16385, the benchmark result:
>>>
>>> Benchmark_Insert-4  118677  9374 ns/op   40960 
>>> B/op   1 allocs/op
>>> Benchmark_Insert2-4 136845  7744 ns/op   40960 
>>> B/op   1 allocs/op
>>>
>>

-- 
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/cebecc7f-3828-474b-8dc4-cad564ca4031n%40googlegroups.com.

[go-nuts] Re: Small number change will affect benchmark results

2021-08-18 Thread tapi...@gmail.com

More specifically, the last parameter (needzero) of mallocgc is not passed 
down to c.nextFree, which causes the memclrNoHeapPointers function is 
called twice in makeslicecopy if the slice size <= 32768.

On Wednesday, August 18, 2021 at 11:06:53 PM UTC-4 tapi...@gmail.com wrote:

> Spent some time on investigating this problem. It is confirmed that, when 
> N == 16384, the memclrNoHeapPointers function is called twice in the 
> Insert2 function. That means the "make+copy` optimization introduced in Go 
> 1.15 will perform worse than the normal route under such situation.
>
> On Wednesday, July 28, 2021 at 10:43:38 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp
>>
>> When N == 16384, the benchmark result:
>>
>> Benchmark_Insert-4  134622  8032 ns/op   32768 
>> B/op   1 allocs/op
>> Benchmark_Insert2-4 132049  8201 ns/op   32768 
>> B/op   1 allocs/op
>>
>> When N == 16385, the benchmark result:
>>
>> Benchmark_Insert-4  118677  9374 ns/op   40960 
>> B/op   1 allocs/op
>> Benchmark_Insert2-4 136845  7744 ns/op   40960 
>> B/op   1 allocs/op
>>
>

-- 
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/8756b448-6718-4ee3-9f52-c83e2f606da8n%40googlegroups.com.

[go-nuts] Re: Small number change will affect benchmark results

2021-08-18 Thread tapi...@gmail.com

Spent some time on investigating this problem. It is confirmed that, when N 
== 16384, the memclrNoHeapPointers function is called twice in the Insert2 
function. That means the "make+copy` optimization introduced in Go 1.15 
will perform worse than the normal route under such situation.

On Wednesday, July 28, 2021 at 10:43:38 AM UTC-4 tapi...@gmail.com wrote:

>
> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp
>
> When N == 16384, the benchmark result:
>
> Benchmark_Insert-4  134622  8032 ns/op   32768 B/op
>1 allocs/op
> Benchmark_Insert2-4 132049  8201 ns/op   32768 B/op
>1 allocs/op
>
> When N == 16385, the benchmark result:
>
> Benchmark_Insert-4  118677  9374 ns/op   40960 B/op
>1 allocs/op
> Benchmark_Insert2-4 136845  7744 ns/op   40960 B/op
>1 allocs/op
>

-- 
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/8e32dd06-4b3c-435a-a452-5a26dec0a474n%40googlegroups.com.

Re: [go-nuts] Re: Why isn't go more popular?

2021-08-14 Thread tapi...@gmail.com

Your attitude is very interesting.

On Friday, August 13, 2021 at 6:42:15 PM UTC-4 devnet@gmail.com wrote:

> Hello tapi,
>
> "Personally, Go will become more popular if we could develop gfx/gui apps 
> in Go with ease."
>
> I think we all here want Go to "smoke some butt" and to push beyond being 
> sucessful to being "the" language of Reason, just an amazing language as it 
> is. But languages evolve and popularity can be achieved by us all 
> implementing solutions in our fields that do the job, fast, efficiently 
> structured and secure.
>
> I foremost believe, if I can motivate Cisco to embrace Go, use and see the 
> benifits of this awesome computer language in Enterprise, Datacenter 
> Networking, then I'm doing my part :-D
> If Cisco learns to love Go, then that will, without a doubt, be "fuel on 
> the fire" :-D
> If we all keep being inspired with this wonderful language, then Go will 
> succeed, as we succeed :-)
> HTH, Scottie 
>
> tapi...@gmail.com  schrieb am Mi., 11. Aug. 2021, 
> 07:45:
>
>> Personally, Go will become more popular if we could develop gfx/gui apps 
>> in Go with ease.
>>
>> On Thursday, August 5, 2021 at 10:20:49 PM UTC-4 santino.f...@gmail.com 
>> wrote:
>>
>>> When you see the ranking of the most liked programming languages, go is 
>>> near c++, a really "hated app". But since is efficient and produces really 
>>> clean code, why no wants like it ?
>>
>> -- 
>> 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/4fff3df0-f7a0-428f-bf9f-2e26cf2512acn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/4fff3df0-f7a0-428f-bf9f-2e26cf2512acn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/213d1660-0a93-4fc2-8542-1148bcd5a889n%40googlegroups.com.

Re: [go-nuts] go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

OK, I just found this: https://github.com/golang/go/issues/44976
It looks the language version is indeed defaulted to 1.16.

On Thursday, August 12, 2021 at 12:36:37 AM UTC-4 tapi...@gmail.com wrote:

> On Thursday, August 12, 2021 at 12:22:08 AM UTC-4 Ian Lance Taylor wrote:
>
>> On Wed, Aug 11, 2021 at 9:16 PM tapi...@gmail.com  
>> wrote: 
>> > 
>> > On Thursday, August 12, 2021 at 12:12:13 AM UTC-4 Ian Lance Taylor 
>> wrote: 
>> >> 
>> >> On Wed, Aug 11, 2021 at 5:44 PM tapi...@gmail.com  
>> wrote: 
>> >> > 
>> >> > But by not specifying the language version in go.mod, I think most 
>> people would expect to use the latest features. 
>> >> > In other words, the default language version gc uses should be the 
>> same as the version of the toolchain containing gc. 
>> >> 
>> >> I believe it is. If I run "go mod init" then in the result go.mod 
>> >> file I see the current language version. 
>> > 
>> > 
>> > My project was created long before. There is not the "go" directive in 
>> go.mod. 
>> > 
>> > Does it mean I must run "go mod tidy" before run other go commands 
>> since Go 1.17? 
>>
>> You will need to edit the "go" line in your go.mod file to your 
>> desired language version, or run "go mod edit -go=1.17". Running "go 
>> mod tidy" will not change the language version in your go.mod file, 
>> nor should it. 
>>
>> Ian 
>>
>
> But "go mod tidy" will add the "go 1.17" line if the directive line 
> doesn't exist there. It will help.
>
> Ian, I still don't understand why gc doesn't think the language version is 
> go1.17 if the directive is missing.
> It looks, without this line, Go 1.14 introduced overlapping interface 
> embedding code compiles okay.
> So gc 1.17rc2 must use a language version in [1.14, 1.17).
>
>
>
>

-- 
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/e5d13236-8fa3-45d7-8cc1-e6d3044938abn%40googlegroups.com.

Re: [go-nuts] go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive



On Thursday, August 12, 2021 at 12:22:08 AM UTC-4 Ian Lance Taylor wrote:

> On Wed, Aug 11, 2021 at 9:16 PM tapi...@gmail.com  
> wrote: 
> > 
> > On Thursday, August 12, 2021 at 12:12:13 AM UTC-4 Ian Lance Taylor 
> wrote: 
> >> 
> >> On Wed, Aug 11, 2021 at 5:44 PM tapi...@gmail.com  
> wrote: 
> >> > 
> >> > But by not specifying the language version in go.mod, I think most 
> people would expect to use the latest features. 
> >> > In other words, the default language version gc uses should be the 
> same as the version of the toolchain containing gc. 
> >> 
> >> I believe it is. If I run "go mod init" then in the result go.mod 
> >> file I see the current language version. 
> > 
> > 
> > My project was created long before. There is not the "go" directive in 
> go.mod. 
> > 
> > Does it mean I must run "go mod tidy" before run other go commands since 
> Go 1.17? 
>
> You will need to edit the "go" line in your go.mod file to your 
> desired language version, or run "go mod edit -go=1.17". Running "go 
> mod tidy" will not change the language version in your go.mod file, 
> nor should it. 
>
> Ian 
>

But "go mod tidy" will add the "go 1.17" line if the directive line doesn't 
exist there. It will help.

Ian, I still don't understand why gc doesn't think the language version is 
go1.17 if the directive is missing.
It looks, without this line, Go 1.14 introduced overlapping interface 
embedding code compiles okay.
So gc 1.17rc2 must use a language version in [1.14, 1.17).



-- 
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/a2d35b18-ecb4-4f77-89ba-cfb8a486f249n%40googlegroups.com.

Re: [go-nuts] go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive



On Thursday, August 12, 2021 at 12:12:13 AM UTC-4 Ian Lance Taylor wrote:

> On Wed, Aug 11, 2021 at 5:44 PM tapi...@gmail.com  
> wrote: 
> > 
> > But by not specifying the language version in go.mod, I think most 
> people would expect to use the latest features. 
> > In other words, the default language version gc uses should be the same 
> as the version of the toolchain containing gc. 
>
> I believe it is. If I run "go mod init" then in the result go.mod 
> file I see the current language version. 
>

My project was created long before. There is not the "go" directive in 
go.mod.

Does it mean I must run "go mod tidy" before run other go commands since Go 
1.17?
 

>
> > BTW, what is the default language version used by gc version go1.17rc2? 
>
> 1.17 
>
> Ian 
>
> > On Wednesday, August 11, 2021 at 4:46:06 PM UTC-4 Ian Lance Taylor 
> wrote: 
> >> 
> >> On Wed, Aug 11, 2021 at 7:45 AM tapi...@gmail.com  
> wrote: 
> >> > 
> >> > // main.go 
> >> > package main 
> >> > 
> >> > func main() { 
> >> > var s = []int{1, 2, 3} 
> >> > var pa = (*[2]int)(s[1:]) 
> >> > println(pa[1]) 
> >> > } 
> >> > 
> >> > $ go run main.go 
> >> > # command-line-arguments 
> >> > ./main.go:6:23: cannot convert s[1:] (type []int) to type *[2]int: 
> >> > conversion of slices to array pointers only supported as of 
> -lang=go1.17 
> >> > 
> >> > Is it the deliberate design? Shouldn't the lang value be the highest 
> language version supported by the current used toolchain? 
> >> 
> >> This is deliberate design. The idea is that if you put "go 1.16" in 
> >> your go.mod file you can reasonably assume that your package will be 
> >> usable by people who are still using Go 1.16. If you don't care 
> >> whether those people can build your package, go ahead and change to 
> >> 1.17. 
> >> 
> >> 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/ba38d473-a6ce-480a-b688-6d2e084fd90dn%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/3a0d3db3-a6d0-47a9-b32c-1d88b96e3391n%40googlegroups.com.

Re: [go-nuts] Re: go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

So, it is a bug? Or not? I'm some confused.

On Wednesday, August 11, 2021 at 9:51:55 PM UTC-4 cuong.m...@gmail.com 
wrote:

> > go run -gcflags="-lang=go1.17" main.go
> >
> > doesn't work either.
>
> Because what was run:
>
> ```
> /Users/cuonglm/sdk/gotip/pkg/tool/darwin_arm64/compile -o 
> $WORK/b001/_pkg_.a -trimpath "$WORK/b001=>" -shared -lang=go1.17 -p main 
> -lang=go1.16 -complete -buildid iarBRwadYSTC65zcr7pK/iarBRwadYSTC65zcr7pK 
> -dwarf=false -D _/Users/cuonglm/t -importcfg $WORK/b001/importcfg -pack 
> ./main.go $WORK/b001/_gomod_.go
> ```
>
> Notice "-lang" is passed two times, and the later "-lang=go1.16" wins.
>
> Cuong Manh Le
> https://cuonglm.xyz
>
>
> On Thu, Aug 12, 2021 at 7:56 AM tapi...@gmail.com  
> wrote:
>
>> BTW, 
>>
>> go run -gcflags="-lang=go1.17" main.go
>>
>> doesn't work either.
>>
>> On Wednesday, August 11, 2021 at 10:45:05 AM UTC-4 tapi...@gmail.com 
>> wrote:
>>
>>> // main.go
>>> package main
>>>
>>> func main() {
>>> var s = []int{1, 2, 3}
>>> var pa = (*[2]int)(s[1:])
>>> println(pa[1])
>>> }
>>>
>>> $ go run main.go 
>>> # command-line-arguments
>>> ./main.go:6:23: cannot convert s[1:] (type []int) to type *[2]int:
>>> conversion of slices to array pointers only supported as of 
>>> -lang=go1.17
>>>
>>> Is it the deliberate design? Shouldn't the lang value be the highest 
>>> language version supported by the current used toolchain?
>>>
>> -- 
>> 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/06c2c090-d73d-4642-9b16-493e716222c4n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/06c2c090-d73d-4642-9b16-493e716222c4n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/51f7a80c-befe-45b5-9521-f30bc8d7d5f1n%40googlegroups.com.

[go-nuts] Re: go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive