Re: [go-nuts] A simplified generics constraint system.

[xingtao zhao]

I have the similar thought as the thread. In terms of a contract, it is 
mainly to express these:

   1. Methods set: this could be easily expressed by interface
   2. Operators set: In go, we could not add or remove the existing 
   operator set for a given type, which is completely inherited from its 
   underlying type. So it is equivalent to explicitly express operation set vs 
   to express the union of underlying types.
   3. Type conversion:
  1. conversion between types with the same underlying type
  2. conversion between numeric types
  3. conversion from concrete types to interface
   
So it is obviously that what we are lacking is: expressing underlying types 
and expressing the combination of them, i.e. union type. So maybe a 
contract could be written like this:

contract Foo(T) {
  int(T) || float64(T) || complex128(T)  // underlying type: int, float64, 
complex128
  InterfaceA(T)// at the same time, it 
should satisfy InterfaceA
}

contract Slice(S) {
  []T(S) && Foo(T)// S is a slice, and retrieve the element type to T, 
and T should match contract Foo
}

contract Map(M) {
  (map[K]V)(M) && Foo(V)  // M is a map, whose value type match contract 
Foo.
}

There is still no way to express that a type should have a field "f" - But 
maybe we can accept this?

In this case, contract is more orthogonal to the existing concepts in go - 
we already have the way to express the method set of a type (interface), it 
is no needed to be able to express it in contract again. 


On Monday, September 17, 2018 at 4:54:04 PM UTC-7, alanfo wrote:

> Thanks for your comment, Patrick.
>
> Although I've relied on compiler magic for my previous proposals, I 
> believe we should keep it to a minimum if we can, The 'union' and 'except' 
> idea would allow us to compose any group of types we want from the basic 
> built-ins and, even within the standard library, it would always be clear 
> from looking at the underlying code exactly what those groups comprised. 
>
> For me that would be a valuable feature and would still be significantly 
> less complex than the draft generics design where every operator used has 
> to be spelled out. Under this proposal, the allowable operators/conversions 
> etc. are implicit from the types used.
>
> Alan
>
> On Monday, September 17, 2018 at 8:16:38 PM UTC+1, Patrick Smith wrote:
>>
>> I think your idea of creating standard contracts to represent similar 
>> types is a good one. However, you don't have to say how those contracts are 
>> written, just what they do. No need for typecheck, union, except, etc. For 
>> example,
>>
>> Integer(T) - T is an integer type
>> Float(T) - T is a floating point type
>> Complex(T) - T is a complex type
>>
>> For contracts in the standard library, we can just invoke "compiler 
>> magic" to explain how they work. Trying to explain the mechanism merely 
>> adds complexity.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics as builtin typeclasses

[xingtao zhao]

Aha, I see what the other set of operators are. While what I thought still 
stands: All of these operators should be handled by the compiler, the user 
no need to think about them at all - let the compiler retrieves them 
implicitly from the function body. In terms of convertible, I think it is 
neat to express them in contract.

On Thursday, September 6, 2018 at 5:12:08 PM UTC-7, Axel Wagner wrote:
>
> On Fri, Sep 7, 2018 at 2:00 AM xingtao zhao  > wrote:
>
>> Try to raise my point here (from another thread):
>>
>> I think all of the operator constraints should be retrieved implicitly. 
>> The proposal of the contract on operators seems a design flaw to me: why do 
>> we express that if < is in the contract, all other operators are also 
>> allowed? I think we do not have to express them in contract. In go, we may 
>> add new methods to a type, but we can not change the operator set. This 
>> means that there are only few operator sets: arithmetic operators, equality 
>> operators, dereference operator, addable(?). I can not figure out other set 
>> of operators.
>>
>
> There is also ==nil (which works differently from == itself), the 
> arithmetic operators split into multiple classes (floats/complex don't have 
> % or <>), you have real/imag/complex, make, make2, make3, an unbounded 
> number of index(K,V), <-, ->, close, [:], copy, append, dereferencing, an 
> unbounded number of convertible(T), assignable(T)…
> I think I've run out.
>
> I'm not saying this is not possible to model with a relatively small set 
> of constraints (especially if you're fine ignoring the less important 
> ones), but it's not *quite* as simple.
>
> And in go, as we never concern about the operators availability before, I 
>> think in generic we could still keep the same and just let the compiler 
>> knows these constraints on operators. 
>>
>> It is still good to be able to explicitly express type conversion in 
>> contract, which is very clear. 
>>
>> On Thursday, September 6, 2018 at 4:29:55 PM UTC-7, Axel Wagner wrote:
>>>
>>> On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor  
>>> wrote:
>>>
>>>> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
>>>>  wrote:
>>>> Interesting point.  But is there any way to solve it short of
>>>> explicitly listing types?  Is there any generics system in any
>>>> language that avoids this problem?
>>>>
>>>
>>> I'm not saying this would be the solution, but since you asked: 
>>> Refinement types (implemented e.g. in Liquid Haskell).
>>>
>>> But FWIW, I was using that as an example. There are others, where e.g. 
>>> range allows ranging, but has vastly different semantics for string, map, 
>>> channel and slice. Or the string(v) example I mentioned, where []rune 
>>> passes the contract
>>> contract foo(v T) {
>>> for i, b := range string(v) {
>>> }
>>> }
>>> But if the author was not considering that, might end up with unexpected 
>>> results when indexing. Or make(T, N), which is semantically very different 
>>> for maps, channels and slices (among other things, for slices, 
>>> len(make(T,N)) == N, for the others len(make(T,N)) == 0).
>>>
>>> The other day I had a lengthy conversation with Rog Peppe, David 
>>> Crawshaw and Nate Finch on twitter and I'd argue that neither of us would 
>>> really count as a Go-novice and we *still* weren't always clear what types 
>>> certain contracts allowed and excluded.
>>>
>>> I believe that these cases will become more and more clear, when it 
>>> comes to actually write a type-checker, so I don't even really think we 
>>> have to talk about all of them or compile a list. I just went away from 
>>> having these conversations with the clear impression that contracts are a 
>>> non-obvious way to express constraints.
>>>
>>> I think it is clear that we are not going to do that.
>>>>
>>>
>>> But there will be *some* implied capabilities, I assume (and FWIW, the 
>>> example I mentioned is IMO pretty similar to ==/!= and />=). For 
>>> example, the design explicitly calls out that == will allow using something 
>>> as a map-key:
>>>
>>> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#map-keys
>>> Note, that contract { var _ map[T]bool } would also work and be 
>>> explicit. But it already shows that at least *some* implicit constraints 
>>> will probably be desirable.
>>

Re: [go-nuts] Re: Generics as builtin typeclasses

[xingtao zhao]

Try to raise my point here (from another thread):

I think all of the operator constraints should be retrieved implicitly. The 
proposal of the contract on operators seems a design flaw to me: why do we 
express that if < is in the contract, all other operators are also allowed? 
I think we do not have to express them in contract. In go, we may add new 
methods to a type, but we can not change the operator set. This means that 
there are only few operator sets: arithmetic operators, equality operators, 
dereference operator, addable(?). I can not figure out other set of 
operators. And in go, as we never concern about the operators availability 
before, I think in generic we could still keep the same and just let the 
compiler knows these constraints on operators. 

It is still good to be able to explicitly express type conversion in 
contract, which is very clear. 

On Thursday, September 6, 2018 at 4:29:55 PM UTC-7, Axel Wagner wrote:
>
> On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor  > wrote:
>
>> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
>> > wrote:
>> Interesting point.  But is there any way to solve it short of
>> explicitly listing types?  Is there any generics system in any
>> language that avoids this problem?
>>
>
> I'm not saying this would be the solution, but since you asked: Refinement 
> types (implemented e.g. in Liquid Haskell).
>
> But FWIW, I was using that as an example. There are others, where e.g. 
> range allows ranging, but has vastly different semantics for string, map, 
> channel and slice. Or the string(v) example I mentioned, where []rune 
> passes the contract
> contract foo(v T) {
> for i, b := range string(v) {
> }
> }
> But if the author was not considering that, might end up with unexpected 
> results when indexing. Or make(T, N), which is semantically very different 
> for maps, channels and slices (among other things, for slices, 
> len(make(T,N)) == N, for the others len(make(T,N)) == 0).
>
> The other day I had a lengthy conversation with Rog Peppe, David Crawshaw 
> and Nate Finch on twitter and I'd argue that neither of us would really 
> count as a Go-novice and we *still* weren't always clear what types certain 
> contracts allowed and excluded.
>
> I believe that these cases will become more and more clear, when it comes 
> to actually write a type-checker, so I don't even really think we have to 
> talk about all of them or compile a list. I just went away from having 
> these conversations with the clear impression that contracts are a 
> non-obvious way to express constraints.
>
> I think it is clear that we are not going to do that.
>>
>
> But there will be *some* implied capabilities, I assume (and FWIW, the 
> example I mentioned is IMO pretty similar to ==/!= and />=). For 
> example, the design explicitly calls out that == will allow using something 
> as a map-key:
>
> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#map-keys
> Note, that contract { var _ map[T]bool } would also work and be explicit. 
> But it already shows that at least *some* implicit constraints will 
> probably be desirable.
>
> I understand the arguments in favor of contracts. Personally, I just tend 
> to think that the disadvantages outweigh them. But that's just, like, my 
> opinion :) There's still lots of time to see.
>
> > Of course that doesn't *have* to happen - you could just literally only
>> > allow the expressions given in the contract, but then the contract
>> > potentially becomes very verbose, as it has to cover lots of ground. For
>> > example, `a[0]` allows integer-indexing, but it technically only allows 
>> to
>> > pass 0. Extending that to arbitrary integers is what's probably going to
>> > happen (and an example of an implicit capability) - but then that code 
>> is
>> > less type-safe then it needs to be, as Arrays already provide tight 
>> bounds
>> > for constant-indices. You can say that `a[N]` then allows indexing with 
>> any
>> > constant <= N (to make those bounds explicit), but at that point I would
>> > criticize that the argument "contracts are just familiar Go syntax" 
>> becomes
>> > less and less convincing, because you are introducing all these special
>> > semantical meanings to expressions.
>>
>> Sure, but I didn't introduce them.  Go already permits indexing [N]int
>> with variables with values larger than N.  Go has no way of expressing
>> that kind of type constraints.  I don't see any reason why we should
>> try to express it in a generics implementation.
>>
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[xingtao zhao]

But we can still using [type T] instead.

On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lance Taylor wrote:
>
> On Thu, Sep 6, 2018 at 5:28 AM,  > wrote: 
> > 
> > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe 
> Meessen: 
> >> 
> >> I understand your example, but it wouldn't be a problem anymore with a 
> >> special character like a $ sign. D use the !. 
> > 
> > 
> > Scala uses [ and ] instead of < and > to avoid the problem that < and > 
> mean 
> > something different depending on the context. 
>
> Note that simple [ and ] don't work in Go, as explained in the 
> generics design draft. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Link: Getting specific about generics

[xingtao zhao]

On Tuesday, September 4, 2018 at 2:26:58 PM UTC-7, Steven Blenkinsop wrote:
>
> If we try to translate contracts into interfaces, the first thing we run 
> into is that there's no way to refer to the dynamic type of the interface. 
> Compare:
>
>  
>
> contract Fooer(t T) {
>
>  interface{ Foo() T }(t)
>
> }
>
>  
>
> to
>
>  
>
> type Fooer interface {
>
>  Foo() ???
>
> }
>
>  
>
> There would have to be some sort of self type:
>
>  
>
> type Fooer interface {
>
>  Foo() self
>
> }
>
>
> Let's say there's a built in convertibleTo constraint
>  
>
> type FooConvertible interface {
>
>  convertibleTo(int)
>
>  Foo() self
>
> }
>
>  
>
> For one thing, this looks like a method. (Aside: This is a problem in the 
> existing generics proposal as well if generic interfaces are allowed, since 
> interface embedding would become ambiguous.) Presuming that we solve this 
> ambiguity, there's a deeper challenge. If I have a generic interface:
>
>  
>
> type Taker(type T) interface {
>
>  Take() T
>
> }
>
>  
>

I was assume that generic interfaces are allowed, which we do not need 
"self" type. In terms of convertableTo, it can be put into the operator 
category, which will be implicitly retrieved from the function body. 
 

> In general, a given concrete type could only satisfy this interface one 
> way. Having
>
>  
>
> type IntAndFloatTaker interface {
>
>  Taker(type int)
>
>  Taker(type float)
>
> }
>

I think this is still not allowed, as they have the same function name 
while different types.
 

>  
>
> wouldn't work because the same type can't implement both func (...) 
> Take() int and func (...) Take() float. convertibleTo (and convertibleFrom) 
> would be unique in this regard, and could get in the way of (say) being 
> able to infer the type parameters of
>
>  
>
> func Take(type T, U Take)(t T) U { t.Take() }
>
>  
>
> T can be inferred from the argument, and you ought to be able to infer U 
> from T, since T can only implement Taker(type U) for exactly one U. But, 
> if convertibleTo exists, this isn't true in general.
>
>
> This doesn't address operators. You could have builtin constraints for 
> each operator, or each set of operators. Or you could have some sort 
> of builtin method corresponding to each operator. These are certainly 
> doable, but designing and naming the constraints/methods is a whole 
> undertaking which the contracts draft seeks to avoid.
>

As we do not have operator overloading, there are only a few sets of 
operations for each type, for example Numeric, Addable, Hashable, Equality, 
etc, and they can never be changed or extended. These are completely 
hiden/invisible from user as operator constraints are retrieved implicitly. 
So we do not have to name them.

The only thing a contract can do while interface can not, is that we can 
not have constraints on structure fiels, as only methods are allowed in 
interface.
 

>
> On Tue, Sep 4, 2018 at 12:52 PM xingtao zhao  > wrote:
>
>> My five cents:
>>
>> 1) the methods of the type template are defined by interface style
>> 2) operators are retrieved implicitly from function body
>> 3) function-calls inside are also retrieved implicitly from the function 
>> body
>>
>> For graph example, we may declare it as:
>>
>> type Edgeser(type E) interface {
>> Edges() []T
>> }
>> type Nodeser(type N} interface {
>> Nodes() from, to N
>> }
>> type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }
>>
>>
>> On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>>
>>> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts 
>>>  wrote: 
>>> > 
>>> > Link: [Getting specific about generics, by Emily 
>>> > Maier](https://emilymaier.net/words/getting-specific-about-generics/) 
>>> > 
>>> > The interface-based alternative to contracts seems like such a natural 
>>> fit- 
>>> > It’s simple, straightforward, and pragmatic. I value those aspects of 
>>> Go’s 
>>> > philosophy and consider them to be features of the language, so it’s 
>>> > encouraging to see a solution that suits them so well. The author also 
>>> does 
>>> > a great job of contextualizing the use cases and debate around 
>>> generics, 
>>> > which I found incredibly helpful. 
>>> > 
>>> > Any thoughts? 
>>>
>>> It's a very nic

Re: [go-nuts] Link: Getting specific about generics

[xingtao zhao]

On Tuesday, September 4, 2018 at 9:52:07 AM UTC-7, xingtao zhao wrote:
>
> My five cents:
>
> 1) the methods of the type template are defined by interface style
> 2) operators are retrieved implicitly from function body
> 3) function-calls inside are also retrieved implicitly from the function 
> body
>

There is no need for 3). We only need to check if the parameter types 
satisfy the constraint for the functions that are called inside.
 

>
> For graph example, we may declare it as:
>
> type Edgeser(type E) interface {
> Edges() []T
> }
> type Nodeser(type N} interface {
> Nodes() from, to N
> }
> type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }
>
>
> On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts 
>>  wrote: 
>> > 
>> > Link: [Getting specific about generics, by Emily 
>> > Maier](https://emilymaier.net/words/getting-specific-about-generics/) 
>> > 
>> > The interface-based alternative to contracts seems like such a natural 
>> fit- 
>> > It’s simple, straightforward, and pragmatic. I value those aspects of 
>> Go’s 
>> > philosophy and consider them to be features of the language, so it’s 
>> > encouraging to see a solution that suits them so well. The author also 
>> does 
>> > a great job of contextualizing the use cases and debate around 
>> generics, 
>> > which I found incredibly helpful. 
>> > 
>> > Any thoughts? 
>>
>> It's a very nice writeup. 
>>
>> It's worth asking how the graph example in the design draft would be 
>> implemented in an interface-based implementation.  Also the syntactic 
>> issues are real. 
>>
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Link: Getting specific about generics

[xingtao zhao]

My five cents:

1) the methods of the type template are defined by interface style
2) operators are retrieved implicitly from function body
3) function-calls inside are also retrieved implicitly from the function 
body

For graph example, we may declare it as:

type Edgeser(type E) interface {
Edges() []T
}
type Nodeser(type N} interface {
Nodes() from, to N
}
type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }


On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>
> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts 
> > wrote: 
> > 
> > Link: [Getting specific about generics, by Emily 
> > Maier](https://emilymaier.net/words/getting-specific-about-generics/) 
> > 
> > The interface-based alternative to contracts seems like such a natural 
> fit- 
> > It’s simple, straightforward, and pragmatic. I value those aspects of 
> Go’s 
> > philosophy and consider them to be features of the language, so it’s 
> > encouraging to see a solution that suits them so well. The author also 
> does 
> > a great job of contextualizing the use cases and debate around generics, 
> > which I found incredibly helpful. 
> > 
> > Any thoughts? 
>
> It's a very nice writeup. 
>
> It's worth asking how the graph example in the design draft would be 
> implemented in an interface-based implementation.  Also the syntactic 
> issues are real. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Is there a way omit the the additional allocation when passing []byte to C function?

[xingtao zhao]

/* C code:

struct PKCS15_Ret {
int error_code;
int len;
};

struct PKCS15_Ret PKCS15_wrap(int hash_type, octet message, octet receive) {
int error_code = PKCS15(hashType, , );
return struct PKCS15_Ret{ error_code, cOct.len };
}

*/

func PKCS15_PLAIN(hashType, RFS int, msg []byte) ([]byte, error) {
// input
mOct := C.octet{
C.int(len(msg)),
C.int(len(msg)),
(*C.char)(unsafe.Pointer([0])),
}

// output
r := make([]byte, RFS)
cOct := C.octet{
C.int(0),
C.int(RFS),
(*C.char)(unsafe.Pointer([0])),
}

rtn := C.PKCS15_wrap(C.int(hashType), mOct, cOct)

if rtn.error_code != 1 {
return nil, {code: int(rtn.error_code)}
}

return r[:rtn.len], nil
}


On Wednesday, November 29, 2017 at 3:12:31 PM UTC-8, xingtao zhao wrote:
>
> Make your C function to accept octet parameter, instead of *octet parameter? 
> Then there will be no allocations.
>
> On Wednesday, November 29, 2017 at 2:39:38 PM UTC-8, Владислав Митов wrote:
>>
>> So no way around 4 allocations for 2 values? 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Is there a way omit the the additional allocation when passing []byte to C function?

[xingtao zhao]

Make your C function to accept octet parameter, instead of *octet parameter? 
Then there will be no allocations.

On Wednesday, November 29, 2017 at 2:39:38 PM UTC-8, Владислав Митов wrote:
>
> So no way around 4 allocations for 2 values? 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Distinct types

[xingtao zhao]

On Monday, October 2, 2017 at 11:10:58 PM UTC-7, Christian Surlykke wrote:
>
> Den mandag den 2. oktober 2017 kl. 21.33.04 UTC+2 skrev Dave Cheney:
>>
>> Back before aliases defined types used to be called named types, which 
>> permitted the existence of unnamed types.
>>
>> map[string]string 
>>
>> is an unnamed type
>>
>> type Dictionary map[string]string
>>
>> is a named type, its name is Dictionary 
>>
>> And the rules of assignment permitted assignment from or to an unnamed 
>> type.
>>
>>
> Aha, I see. Thanks for clarifying. 
>
> br. Chr.
>  
>
>> On Tuesday, 3 October 2017 06:26:44 UTC+11, Christian Surlykke wrote:
>>>
>>> Forgive me if this has been asked before. I've not been able to find a 
>>> diskussion about it.
>>>
>>> A snippet like this
>>>
>>> type AppleCount uint32
>>>
>>> var i uint32 = 7
>>>
>>>
Isn't uint32 an unnamed type?
 

> var ac AppleCount = i
>>>
>>> why did this fail?
 

>
>>> will fail to compile with an error like:
>>>
>>> cannot use i (type uint32) as type AppleCount in assignment
>>>
>>>
>>> OTOH code like this:
>>>
>>> type Dictionary map[string]string
>>> var m map[string]string = make(map[string]string)
>>> var d Dictionary = m
>>>
>>>
>>> compiles just fine.
>>>
>>> There is this about type definitions in The Go Programming Language 
>>> Specification:
>>>
>>> *A type definition creates a new, distinct type with the same underlying 
>>> type and operations as the given type, and binds an identifier to it.*
>>>
>>> TypeDef = identifier Type .
>>>  
>>> *The new type is called a defined type. It is different from any other 
>>> type, including the type it is created from.*
>>>
>>>
>>> which I would take to mean that the second snippet should be invalid. 
>>>
>>> Is this a bug or 'working as intended'? If it's working as intended, can 
>>> anyone explain the reasoning behind this?
>>>
>>> br. Christian Surlykke
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: append() gotcha!

[xingtao zhao]

Sometimes, I use:
a := []int{ 1, 2, 3 }
b : = append([]int(nil), a...)

to copy a slice.

On Wednesday, August 16, 2017 at 12:31:13 PM UTC-7, Nate Finch wrote:
>
> Wrote it up as an issue: https://github.com/golang/go/issues/21482
>
> and I agree that using append to assign to a different variable than the 
> one in the append call is almost always going cause surprising behavior 
> but it's less clearly a mistake than append with only a single argument.
>
> On Wednesday, August 16, 2017 at 9:09:37 AM UTC-4, Val wrote:
>>
>> Agreed, append with only one argument doesn't look good and should be 
>> vetted.
>>
>> As a superset of this problem, any use of
>>   *a* = append(*b*, *c*)
>> with *b* != *a* (i.e. not assigning back to the same slice variable) 
>> looks either broken or cryptic me.
>> This holds whether *c* is zero or one or more variadic elements.
>> I mean, while there are a few usages where it is written on purpose, it 
>> makes reading and reasoning much more difficult.
>> Val
>>
>> On Wednesday, August 16, 2017 at 4:53:16 AM UTC+2, DrGo wrote:
>>>
>>> Hello,
>>>
>>> The following compiles as well as evades scrutiny by go Vet (and many a 
>>> human reviewer) resulting in perplexing bugs. What purpose calling append() 
>>> with only one argument serves? Shouldn't it be banned?
>>>
>>>
>>> ```
>>> var byteArray= []byte{'A', 'B',}
>>>
>>> func main() {
>>> buf:=[]byte {'C'}
>>> buf = append(byteArray)  //<--- gotche meant: buf = append(*buf*, 
>>> byteArray)
>>> fmt.Println(string(buf))
>>> }
>>> ```
>>> https://play.golang.org/p/jP8NGiEN9A
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Casting []byte to []uint64

[xingtao zhao]

I think you need to check if inhdr.Data is aligned with 8 bytes as well.

On Sunday, February 26, 2017 at 2:54:00 PM UTC-8, Bill Katz wrote:
>
> Hi,
>
> We'd like to do a zero-copy conversion of []byte to []uint64 where the 
> underlying memory for the byte slice is properly aligned for N uint64 
> values.  After looking at (6) in the unsafe package documentation 
> , I'm wondering if the code below 
> is valid because I only use reflect.SliceHeader as pointers, and it seems 
> to fit pattern 6.
>
> https://play.golang.org/p/FxxKIK08pX
>
> package main
>
> import (
> "fmt"
> "reflect"
> "unsafe"
> )
>
> func byteToUint64(b []byte) (out []uint64, err error) {
> inhdr := *(*reflect.SliceHeader)(unsafe.Pointer())
> if inhdr.Len % 8 != 0 {
> err = fmt.Errorf("cannot convert non-aligned []byte length (%d) to 
> []uint64", inhdr.Len)
> return
> }
> if inhdr.Cap % 8 != 0 {
> err = fmt.Errorf("cannot convert non-aligned []byte capacity (%d) to 
> []uint64", inhdr.Cap)
> return
> }
> outhdr := *(*reflect.SliceHeader)(unsafe.Pointer())
> outhdr.Len = inhdr.Len / 8
> outhdr.Cap = inhdr.Cap / 8
> outhdr.Data = inhdr.Data
> out = *(*[]uint64)(unsafe.Pointer())
> return
> }
>
> func main() {
> b := make([]byte, 24)
> u, err := byteToUint64(b)
> if err != nil {
> fmt.Println(err)
> } else {
> fmt.Printf("b: %v\n", b)
> fmt.Printf("u: %v\n", u)
> fmt.Printf("len(u) = %d, cap(u) = %d\n", len(u), cap(u))
> u[0] = 15
> fmt.Printf("Set u[0] to 15\n")
> fmt.Printf("b: %v\n", b)
> fmt.Printf("u: %v\n", u)
> u[2] = 255
> fmt.Printf("Set u[2] to 255\n")
> fmt.Printf("b: %v\n", b)
> fmt.Printf("u: %v\n", u)
> }
> }
>
> Outputs:
>
> b: [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> u: [0 0 0]
> len(u) = 3, cap(u) = 3
> Set u[0] to 15
> b: [15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> u: [15 0 0]
> Set u[2] to 255
> b: [15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 0 0 0 0 0 0 0]
> u: [15 0 255]
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Thinking OO virtual function in Go

[xingtao zhao]

Or this implementation: https://play.golang.org/p/5GqspHDJnF
But I prefer the previous version: https://play.golang.org/p/3_PDTCcJTi.

On Thursday, November 24, 2016 at 6:21:24 PM UTC-8, xingtao zhao wrote:
>
> Hi Tong,
>
> Another implementation is https://play.golang.org/p/3_PDTCcJTi.
> You could merge the interface Animal and ExtraFactsor together if this 
> extra behavior is not needed. It is listed there just for demonstration.
>
> On Thursday, November 24, 2016 at 12:14:37 AM UTC-8, Nick Patavalis wrote:
>>
>> On Thu, Nov 24, 2016 at 10:00 AM, Haddock <ffm...@web.de> wrote: 
>> > 
>> > This is merely resorting to a shared function. This does not really 
>> > cover overwriting in the OO sense. The article I mentioned shows how 
>> > to do this: 
>> > 
>> http://objectscape.blogspot.de/2013/09/inner-pattern-to-mimic-method.html 
>>
>> Not really! Tong Sun's Animal.Output() method (with a Speaker 
>> argument) is pretty-much "isomorphic" with Plohmann's Mamal.ActInner() 
>> method (with an Animal argument). Maybe it's not as clearly named, but 
>> it is pretty-much the same approach. 
>>
>> /npat 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Thinking OO virtual function in Go

[xingtao zhao]

Hi Tong,

Another implementation is https://play.golang.org/p/3_PDTCcJTi.
You could merge the interface Animal and ExtraFactsor together if this 
extra behavior is not needed. It is listed there just for demonstration.

On Thursday, November 24, 2016 at 12:14:37 AM UTC-8, Nick Patavalis wrote:
>
> On Thu, Nov 24, 2016 at 10:00 AM, Haddock  
> wrote: 
> > 
> > This is merely resorting to a shared function. This does not really 
> > cover overwriting in the OO sense. The article I mentioned shows how 
> > to do this: 
> > 
> http://objectscape.blogspot.de/2013/09/inner-pattern-to-mimic-method.html 
>
> Not really! Tong Sun's Animal.Output() method (with a Speaker 
> argument) is pretty-much "isomorphic" with Plohmann's Mamal.ActInner() 
> method (with an Animal argument). Maybe it's not as clearly named, but 
> it is pretty-much the same approach. 
>
> /npat 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] interface as valid method receivers ?

[xingtao zhao]

I think the original proposition is not to add default implementation for 
the methods in an interface. The proposal was just want to add extra 
methods to the interface. These methods will not get into the vtable of the 
interface. Yes, this can be implemented by package level function, but it 
is not as nature as adding methods directly to the interface.

On Wednesday, October 19, 2016 at 12:35:33 PM UTC-7, Viktor Kojouharov 
wrote:
>
>
>
> On Wednesday, October 19, 2016 at 10:16:50 PM UTC+3, Jan Mercl wrote:
>>
>> On Wed, Oct 19, 2016 at 8:58 PM Viktor Kojouharov  
>> wrote:
>>
>> > Not really, as this is all hypothetical, it might be implemented in a 
>> way so that any type that wants to satisfy an interface with default 
>> methods has to at least implement all non-default ones. That is to say, 
>> with the above example interface, any and all types will be able to match, 
>> since the interface doesn't define any other methods (in a sense, it turns 
>> into interface{}). However, if a type wishes to define any method that has 
>> a default implementation, it can do so, and that implementation will be 
>> used.
>>
>> This can serve as a good answer to the question in the thread title. I 
>> mean, hypothetically allowing interface types as method receivers makes 
>> things less intuitive to use, more complex to specify, implement and 
>> understand to source code reader.
>>
>
> I disagree. I see no evidence nor reason why such a feature would make 
> things less intuitive or more complex. On the contrary, handling a feature 
> in this way seems quite intuitive.
>  
>
>>
>> -- 
>>
>> -j
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] interface as valid method receivers ?

[xingtao zhao]

Why not make it a compiling time error? 

For example, for a struct: "type Foo has both field and method named 
DoSomething"
type Foo struct {
DoSomething func()
}

func (f Foo) DoSomething() {
}


And for interface version:

type Foo interface { 
func DoSomething() 
} 

func (f Foo) DoSomething() { 
} 

it is more straight forward: "Foo.DoSomething redeclared"

On Tuesday, October 18, 2016 at 11:27:36 AM UTC-7, Konstantin Khomoutov 
wrote:
>
> On Tue, 18 Oct 2016 11:11:59 -0700 (PDT) 
> parais...@gmail.com  wrote: 
>
> > Obviously in Go this is a compile time error : 
> > 
> > type Foo interface {} 
> > 
> > 
> > func (f Foo) DoSomething(){} 
> > 
> > 
> > I wonder if there is some technical limitations that make it 
> > undesirable or hard to implement, or it's just that Go designers 
> > didn't think it is a relevant feature. 
> > 
> > I personally think there is it could be handy in some situations, 
> > instead of having to write a function without receiver, it could 
> > allow to attach behavior to interfaces automatically 
> > instead of the explicit : 
> > 
> > func DoSomething(f Foo){} 
> > 
> > 
> > what is your opinion on the matter ? Unfortunately I wasn't able to 
> > catch anyone of the Go team during the recent conference in Paris to 
> > ask that question. 
>
>   type Foo interface { 
>   func DoSomething() 
>   } 
>
>   func (f Foo) DoSomething() { 
>   } 
>
>   var f Foo 
>
>   f.DoSomething() 
>
> How do you propose to distinguish these two DoSomething()-s? 
>
> More to the point: how could anyone infer what's about to get called 
> from looking at that "f.DoSomething()" expression even if there could 
> be no conflict as in my contrived example -- is it a call on an 
> "interface itself" or on a concrete type an interface value contains? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Sorting slice of structs

[xingtao zhao]

Or:

sort.Sort(Courses(course))

On Tuesday, September 20, 2016 at 10:50:15 AM UTC-7, Jan Mercl wrote:
>
> Types []Course and Courses are distinct types. courses have type []Courses 
> because that's what the parameter to make is. Change it to Courses, ie.
>
> courses := make(Courses, maxrow)
>
> On Tue, Sep 20, 2016, 19:44 Arie van Wingerden  > wrote:
>
>> Hi,
>>
>> Still a beginner ... first take at a bit more difficult thing.
>>
>> I cannot get this https://play.golang.org/p/qgBLH0r_vq to work.
>>
>> Compiler says:
>> cannot use courses (type []Course) as type sort.Interface in argument to 
>> sort.Sort:
>> []Course does not implement sort.Interface (missing Len method)
>>
>> However, I thought I need the Len method for []Courses instead of 
>> []Course!
>>
>> Pleas help.
>>
>> TIA
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.