On Thu, Jun 18, 2020 at 4:59 PM Bruno Albuquerque <b...@gmail.com> wrote: > > It looks to me one point of contention on using interfaces instead of > contracts is the fact that now interfaces have to support type lists but only > when used as contracts. This, no matter how you slice it, looks ugly.
I agree, it looks ugly. I wrote a proposal (first proposal?) about a year ago about these type lists. The idea with type lists had two aspects then: first, you have to somehow use primitive types as constraints without operator overloading, and second, you can use existing types as constraints instead of dealing with type traits. I understand that the concept of contracts could be confusing. But I believe changing the definition of interfaces would be even more confusing. Interfaces already cause a lot of problems for people coming from other languages like Java. One suggestion could be using type lists where needed: func f(type T int string bool) (input T) This can get verbose, so maybe a new keyword? typelist TL int, string,bool func f(type T TL)(input T) This goes back to contracts though. Maybe "contract" could be renamed to less confusing "typelist"? Also, there is no point in restricting typelist to primitives: typelist TL int, string, bool, SomeInterface I think such a typelist can do everything the interface-with-typelist can without changing the definition of what interface means. Just some thoughts, I'm still reading the design doc... > > Now type lists are there to support built-in operations like operators in > general and range support. there is a finite (and relatively small) set of > combinations of types that make sense. > > Also there is already the intention of providing "contracts" like Comparable > in pre-existing libraries. > > There is also precedent for "magical" things in the language (range can > operate on slices of any type). > > So, with all that in mind, wouldn't it be possible for the language to offer > all the possible reasonable type combinations as built-in contracts in a way > that they could be embedded in other interfaces? They would be a bit magical > as their constraints are, under the hood, on types (not methods), but I guess > this would make things less ugly. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEd86Tz%2B6vfp1C_kFA82Mw5z__%3D5SLrc%3Dnu3od1AKBVCCRtBPQ%40mail.gmail.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrSqTkYkxmk8EKAw%3D4_9ECWguNZGN_1W9Z2AmXk0Zz9AA%40mail.gmail.com.
