Some of the reasons for contracts have been covered by others in this thread already. But somehow one of the biggest has not. Contracts make it possible to change the implementation of a generic function in a published package. Without a contract it would be super easy for a seemingly simple change to a published generic function to break clients of that function. While not foolproof, the presence of a contract means that, if the contract does not change, then changes to the generic code should, minimally, not cause compilation errors in client code. And, if intelligently created, should offer a degree of confidence that such changes won't functionally break client code either.
Personally, I don't expect they will be hard to write. After decades of experience with many languages, my gut tells me that the vast majority of contracts written by the vast majority of "general" programmers will be trivial. Easily written and read. More advanced contracts would be less common, but I suspect that common idioms will quickly emerge for the more advanced constraints. I do have some concerns about reading more complicated contracts. However, that can be alleviated by reasonable line commenting of complicated contracts. Additionally, if the error messages for violating a constraint when calling generic function are well crafted, that should make it even easier. But I would rather have to do some extra thinking on rare occasion, than have to learn some whole new language for contracts. As for: It runs parallel to my concerns about language compactness, too. > Again, I predict that most contracts will be a few lines long. Secondly, golang is not a language of compactness. Many of the design decisions make that clear. And idiomatic go favors clarity over brevity. It can be hard to adjust to, but overall it's a win. Finally, if you are writing so much generic code that the contracts are any appreciable percentage of your code base, then you are probably way off the rails anyway. My 2ยข On Tuesday, September 11, 2018 at 10:57:30 AM UTC-4, Jeff wrote: > I am a semi-advanced hobbyist. I have a BSCEE degree, but no professional > programming experience. I have been programming for > 30 years and have > written small programs in easily 20+ different languages during that time. > So, while not a professional programmer, I am not exactly a novice. > > I've been following some of the contracts proposal discussions and frankly > I have been a bit lost. I think I have a good handle on interfaces, but > this contracts stuff confuses me. One of Go's strengths is that the > language is relatively easy to grasp. The code is generally relatively > straightforward. People seem to draft code that leans more toward > readability instead of toward "clever" but less easily understood. I have > looked at the source code of many packages. It is rare that I cannot > follow the code. I cannot say this about many other languages. My fear is > this contracts proposal will kill my ability to read and understood code of > others. > > I recall using generics many years ago in Ada and did not recall them > being so confusing. So, I went back and looked at the Ada implementation. > See, e.g., https://en.wikibooks.org/wiki/Ada_Programming/Generics > <https://www.google.com/url?q=https%3A%2F%2Fen.wikibooks.org%2Fwiki%2FAda_Programming%2FGenerics&sa=D&sntz=1&usg=AFQjCNEtM6JYYqRIDrDXiI6wSbWuProlEw>. > > Honestly, I find this general approach to be easier to follow than > contracts. Based on the link, it has some similarities with C++ templates. > I have some basic experience with C++, but I have no experience with C++ > templates. > > TLDR; So why contracts and not templates or something else? Is there a > benefit to contracts that I don't appreciate (very likely, cause I don't > understand them)? Are there issues with a template approach? If this has > been addressed elsewhere, please provide links. I'd like a better > understanding as to why the Go team has chosen to explore contracts over > other approaches. > > Jeff > -- 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.
