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
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
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
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
g 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 e
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
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 {
.error_code != 1 {
return nil, &Error{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.
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 t
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
>
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
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
>
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_PDT
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:
>
>
If we adopt the syntax like &int(0), there will be no ambiguities, even for
the example Ian showed: the two cases will be written as
&[]interface{}(nil) and &[]interface{}{nil}
you may argue that this is confusing, but both []interface{}(nil) and
[]interface{}{nil} are available already.
On Fri
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
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) DoSome
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)
>
> O
I totally agree that I always want generics mainly when I am writing a
framework. But I do not agree with you on that "go is pretty much a
language for writing applications". I don't think go is powerful enough
that we do no need any framework. I don't think we can always develop
applications f
For example:
type Int int
func (i Int) Add(j Int) Int { return i + j }
type Number> interface {
Add(j T) T
}
If we want Int satisfy the interface Number, we have to create two
versions of function Int.Add, one for concrete type Int, one with generic
type T
And if we want to support:
var
That was my original thought. While later I realized that we still need
some parameter check in the callee code to satisfy the interface matching
(the generic version of each function in my proposal). And we need special
assembler function for dynamic interface cast.
On Monday, June 20, 2016 at
the complier speed a lot.
Anyway, looking forward to any comments for the valuable part in my
proposal. Thanks!
On Tuesday, June 14, 2016 at 6:22:08 PM UTC-7, Ian Lance Taylor wrote:
>
> On Tue, Jun 14, 2016 at 6:04 PM, xingtao zhao > wrote:
> > Here is my proposal fo
Here is my proposal for generic in go:
https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
Many parts has not been finished, and just initial thoughts. In the
proposal, I want to keep back compatibility. And I try to add the
orthogonal feature only a
23 matches
Mail list logo
