3 ms·

I still don’t get contracts. Can someone explain it for the slow like me?

biggestlou 7y ago
What in the draft is unclear?
marcus_holmes 7y ago
as I understand it (and I may be misunderstanding it), contracts are exactly like interfaces, except the type of parameters/return values is left to the implementation. So an interface of "adder" would look like: type adder interface { Add(int) int } and it would only be able to support adding an int to something, and returning an int. Doing this: func AddStrings(a adder, b string) string { return a.Add(b) } will break A contract for "adder" would look like: contract adder(T) { T Add (T) T } You can then use this in a function by: func addTheThings(type T adder)(t1, t2 T) T { return t1.Add(t2) } which can then use any type that has an Add method //can't extend native types, so we have to create an alias and extend that type Addstring string func (a Addstring)Add(b Addstring) Addstring { return a+b } func (a Banana)Add(b Banana) Banana { return Banana{a.Count + b.Count} } then your "addTheThings" function can operate on strings (via the Addstring type) and Bananas, and anything else that fulfills the contract. So the original example: func AddStrings(a adder, b string) string { if as,ok := a.(Addstring); ok { return a.Add(b) } //raise an error here } On a separate note, why is "contract" becoming a keyword instead of "type foo contract {}"? Making the common business concept of "contract" a keyword is likely to break backward compatibility for some code bases
- dilap 7y ago
  > On a separate note, why is "contract" becoming a keyword instead of "type foo contract {}"? I was wondering about this too. It also just feels really weird since it's a different construction than any of the other types. Maybe the thinking is because a contract is not a type? But so what... On first blush, it also feels weird that type is coming _before_ the type arguments, rather than after -- since types for normal arguments come after the argument. E.g., Map(T, U type)(t []T, f func(T) U) []U feels much more consistent than Map(type T, U)(t []T, f func(T) U) []U no? (Perhaps it complicates parsing, though?)
  - DangitBobby 7y ago
    I think calling it a type would be confusing. It's not a type, it's a description of a behaviors of potential types.
  - ithkuil 7y ago
    "var n int" means "in this scope, declare variable n to be if type int". "type T adder" means "in this scope, declare T to be a type adhering to the adder contract"
    - dilap 7y ago
      Good way to think of it.
- DangitBobby 7y ago
  They address backwards compatibility in the document. It will only be a keyword in certain contexts so that any valid go1 code will still be valid go2 code.
  - marcus_holmes 7y ago
    ah, I missed that. Cool
- gigatexal 7y ago
  Well done. I understood that. Thank you.

What in the draft is unclear?

as I understand it (and I may be misunderstanding it), contracts are exactly like interfaces, except the type of parameters/return values is left to the implementation. So an interface of "adder" would look like: type adder interface { Add(int) int } and it would only be able to support adding an int to something, and returning an int. Doing this: func AddStrings(a adder, b string) string { return a.Add(b) } will break A contract for "adder" would look like: contract adder(T) { T Add (T) T } You can then use this in a function by: func addTheThings(type T adder)(t1, t2 T) T { return t1.Add(t2) } which can then use any type that has an Add method //can't extend native types, so we have to create an alias and extend that type Addstring string func (a Addstring)Add(b Addstring) Addstring { return a+b } func (a Banana)Add(b Banana) Banana { return Banana{a.Count + b.Count} } then your "addTheThings" function can operate on strings (via the Addstring type) and Bananas, and anything else that fulfills the contract. So the original example: func AddStrings(a adder, b string) string { if as,ok := a.(Addstring); ok { return a.Add(b) } //raise an error here } On a separate note, why is "contract" becoming a keyword instead of "type foo contract {}"? Making the common business concept of "contract" a keyword is likely to break backward compatibility for some code bases

dilap 7y ago
> On a separate note, why is "contract" becoming a keyword instead of "type foo contract {}"? I was wondering about this too. It also just feels really weird since it's a different construction than any of the other types. Maybe the thinking is because a contract is not a type? But so what... On first blush, it also feels weird that type is coming _before_ the type arguments, rather than after -- since types for normal arguments come after the argument. E.g., Map(T, U type)(t []T, f func(T) U) []U feels much more consistent than Map(type T, U)(t []T, f func(T) U) []U no? (Perhaps it complicates parsing, though?)
- DangitBobby 7y ago
  I think calling it a type would be confusing. It's not a type, it's a description of a behaviors of potential types.
- ithkuil 7y ago
  "var n int" means "in this scope, declare variable n to be if type int". "type T adder" means "in this scope, declare T to be a type adhering to the adder contract"
  - dilap 7y ago
    Good way to think of it.
DangitBobby 7y ago
They address backwards compatibility in the document. It will only be a keyword in certain contexts so that any valid go1 code will still be valid go2 code.
- marcus_holmes 7y ago
  ah, I missed that. Cool
gigatexal 7y ago
Well done. I understood that. Thank you.