On Thu, Aug 13, 2020 at 6:30 PM Ian Lance Taylor <i...@golang.org> wrote:
> > If I understand you correctly, we changed that when we added the > constraint type inference section. See the updated > > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference > section. This change creates two types of type parameters: free type parameters and *associated* type parameters. And it seems like type parameter lists should always be specified in the following order: 1. Free type parameters which *cannot* be inferred based on value arguments to the function, followed by 2. Free type parameters which *can* be inferred based on value arguments to the function, followed by 3. Associated type parameters. Would this be something that would just be part of style guides, or could it be enforced in some way (perhaps by a lint)? Also, is there any suggested way for APIs to document where the "stops" are between these three categories of type parameters? Currently, the only possible delimiter is ',', which means type parameter lists currently have to appear uniform unless you use inline comments. On Thu, Aug 13, 2020 at 6:30 PM Ian Lance Taylor <i...@golang.org> wrote: > On Thu, Aug 13, 2020 at 3:09 PM roger peppe <rogpe...@gmail.com> wrote: > > > > I do feel that the "all or nothing" nature of type parameter lists (if > you specify one type parameter, you must explicitly specify all of the > others too, even if they could otherwise be inferred) is likely to get in > the way here. I'd like to see a way to specify some type parameters and not > others, so that constraint type inference can work even when, for example, > there's a generic return type parameter that can't be inferred from the > arguments. We could potentially use an underscore for that. > > If I understand you correctly, we changed that when we added the > constraint type inference section. See the updated > > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference > section. > > Ian > > -- > 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/CAOyqgcVvLvuAVy%3DWVA2n4wCcpEKNfbxTN-d_K%3Dz8kz1oiK9Z3g%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/CANjmGJujty1Xg03MttK4aFH_3GMs6BEQNWwZyfOwySKBv2_gnA%40mail.gmail.com.
