cybercyst/go
1
0
Fork 0
mirror of https://github.com/golang/go.git synced 2025-05-06 08:03:03 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Updated Go2GenericsFeedback (markdown)

Nodir Turakulov 2018-08-29 20:33:51 -07:00
parent 83a31e6666
commit 4e84f1739d
1 changed files with 14 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
Go2GenericsFeedback.md

@ -80,3 +80,16 @@ As the amount of feedback grows, please feel free to organize this page by speci
- Seebs: [Feedback a bit long to inline](https://gist.github.com/seebs/8f943b8b15a8c63c28c7f6f4e5ca6c53), August 2018. Summary basically "I would like a way to specify one contract for each of two types rather than one contract for both types", and "I would prefer `map[T1]T2` to `t1var == t1var` as a canonical form of "T1 must be an allowable map key". - Seebs: [Feedback a bit long to inline](https://gist.github.com/seebs/8f943b8b15a8c63c28c7f6f4e5ca6c53), August 2018. Summary basically "I would like a way to specify one contract for each of two types rather than one contract for both types", and "I would prefer `map[T1]T2` to `t1var == t1var` as a canonical form of "T1 must be an allowable map key".
- Sean Quinlan: I find the contract syntax quite confusing. For something that is supposed to defined exactly what is needed, it can contain all sorts of cruft that does not impact the contract. Moreover, to quote from the design: "We don’t need to explain the meaning of every statement that can appear in a contract body". That seems like the opposite of what I would want from a contract. The fact one can copy the body of a function into a contract and have it work seems like a bug to me, not a feature. Personally, I would much prefer a model that unifies interfaces and contracts. Interfaces feel much closer to what I would like a contract to look like. - Sean Quinlan: I find the contract syntax quite confusing. For something that is supposed to defined exactly what is needed, it can contain all sorts of cruft that does not impact the contract. Moreover, to quote from the design: "We don’t need to explain the meaning of every statement that can appear in a contract body". That seems like the opposite of what I would want from a contract. The fact one can copy the body of a function into a contract and have it work seems like a bug to me, not a feature. Personally, I would much prefer a model that unifies interfaces and contracts. Interfaces feel much closer to what I would like a contract to look like.
- Nodir Turakulov: Please clarify
> Packages like container/list and container/ring, and types like sync.Map, will be updated to be compile-time type-safe.
and
> The math package will be extended to provide a set of simple standard algorithms for all numeric types, such as the ever popular Min and Max functions.
FWIU adding type parameter(s) to an existing type/func makes programs that use the type/func invalid.
How `math.Max` will be changed?
Is the intention to make backward-incompatible changes and write tools to automatically convert code to Go2?
What is the general recommendation for authors of other libraries that provide funcs and types that currently operate with `interface{}`?
Were default values for type parameters considered? e.g. type parameter for Max would default to `float64` and type parameter for `"container/list".List` would default to `interface{}`