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
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
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
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/inv
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 {
: 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
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
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:
>
>
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
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)
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)
>
>
17 matches
Mail list logo
