On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton <w...@iri-labs.com> wrote:
> My intuition is that interfaces would be obsolete -- and that's a very
> good thing.
>
They wouldn't. You can't have heterogeneous lists with contracts. For
example, say you have a Reader contract:
contract Reader(r R) {
var (
n int
err error
p []byte
)
n, err = r.Read(p)
}
You can't use that to implement, say, io.MultiReader:
func MultiReader(type R Reader) (readers ...R) R {
return &multiReader{readers} // Type error: Must return R, not
*multiReader
}
func Foo() {
r1 := bytes.NewReader([]byte("Hello "))
r2 := strings.NewReader("world")
r3 := MultiReader(r1, r2) // Type error: Uses different types in places
of R
}
Saying that contracts subsume interface is a bit like saying that generic
functions in Haskell subsume type classes. They are different things with
different (but overlapping) uses.
You could implement interface
> in terms of contract as some sort of bridge for compatibility. But if the
> proposal could come up with a way to extend the interface syntax with
> contract-like semantics, perhaps the overlap between the two could just
> disappear.
>
> As for the question in the proposal about implementation by interface or
> not (compilation speed
> vs execution speed), my own use cases often require re-thinking something
> without interfaces
> (like the heap in my sat solver) for performance. Here's a thumbs up for
> execution speed and
> hearty "go for it" for compiler writers to make it fast :)
>
> Nice work on the proposal.
>
> Scott
>
> On Friday, 31 August 2018 18:47:45 UTC+2, Daniela Petruzalek wrote:
>>
>> I agree with Tristan in regards to orthogonality.
>>
>> Seeing the draft with all those complexities added to the language made
>> me quite uneasy about this proposal. When I first started learning Go I was
>> one of the first people to raise a hand and complain about the lack of
>> generics in the language. Now, a year later, after learning about Go proper
>> idioms, I strongly regret my previous stance. I was trying to make Go
>> another language that was not Go. I didn't want to learn to write idiomatic
>> Go code, I wanted to write Go in the same way I used to write C++ (for
>> instance). That was wrong on so many levels.
>>
>> I'm now sitting in the fence in regards to the generics addition to the
>> language. My previous arguments don't hold anymore. I like how the current
>> Go language forces our intentions to be explicit rather than hiding the
>> real code under some clever abstractions that few people understand. I feel
>> that I became a better programmer that way, thinking about the collective
>> before trying to please myself showing how smart I am. I feel it also
>> encourages collaboration since it's really easy to get an overall
>> understanding of the language. It's accessible for junior developers and
>> enthusiasts since there are fewer concepts to learn, yet they provide some
>> powerful abstractions. Look at the things that were built with Go...
>> Kubernetes, Docker... it's a really powerful language while still being
>> truthful to its simplified flow control, simplified (yet verbose) error
>> handling, simplified data structures...
>>
>> I strongly wish that a generics proposal would stay true to the Go's
>> simplicity principle, but I somehow don't feel this proposal does meet that
>> requirement at it's current state.
>>
>> Sorry to hijack the thread!
>>
>> Best,
>>
>> Dani
>>
>> Em sex, 31 de ago de 2018 às 10:54, Tristan Colgate <tcol...@gmail.com>
>> escreveu:
>>
>>> Also, and I think this probably applies to the existing syntax in the
>>> design.
>>> This example seems like a pathological use of generics. What would be
>>> the advantage over just declaring the function takes a Stringer? Am I
>>> missing something (presumably this is potentially avoids the interface call
>>> allocation?).
>>> This is a good example of my gut feeling about generics, I realise
>>> they'll be valuable, but do they devalue interfaces? They do not seem like
>>> an orthogonal feature. Of the two, interfaces feel like they encourage me
>>> to write better structured code.
>>> This could also just be fear of change.
>>>
>>>
>>> On Fri, 31 Aug 2018 at 14:34 'Axel Wagner' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
>>>> A contract can include multiple type parameters:
>>>> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#mutually-referential-type-parameters
>>>> AIUI your syntax can't cover that. And FWIW, I find the syntax of
>>>> contracts in the doc far less "magic" than yours, but YMMV of course.
>>>>
>>>> On Fri, Aug 31, 2018 at 6:43 AM Manlio Perillo <manlio....@gmail.com>
>>>> wrote:
>>>>
>>>>> I just read the "official" proposal for Go2 generics and contracts.
>>>>> The current proposal makes the function syntax more complex, and the
>>>>> syntax for the contract is a bit magic.
>>>>>
>>>>> What about something like:
>>>>>
>>>>>
>>>>> type stringer template
>>>>>
>>>>> contract (x stringer) {
>>>>> var s string = x.String()
>>>>> }
>>>>>
>>>>> func Stringify(s []stringer) (ret []string) {
>>>>> for _, v := range s {
>>>>> ret = append(ret, v.String())
>>>>> }
>>>>> return ret
>>>>> }
>>>>>
>>>>> instead of
>>>>>
>>>>>
>>>>> contract stringer(x T) {
>>>>> var s string = x.String()
>>>>> }
>>>>>
>>>>> func Stringify(type T stringer)(s []T) (ret []string) {
>>>>> for _, v := range s {
>>>>> ret = append(ret, v.String())
>>>>> }
>>>>> return ret
>>>>> }
>>>>>
>>>>>
>>>>> Thanks
>>>>> Manlio
>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>> --
>>>> 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.
>>>>
>>> --
>>> 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.
>>>
>> --
> 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.
>
--
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.
