@ianlancetaylor , thank you for the quick reply. The reason I was asking is because potentially this could have been used to fix `type ObjectIdentifier []int` in the `encoding/asn1` package and the `crypto/x509` package. Currently these package are not fully compliant with the ASN.1 specification, which means in practice some certificates cannot be parsed.
I am trying to fix the encoding/asn1 and crypto/x509 package by adding support for OID values that are greater than 2^31. There are multiple ways to fix the issues, and unfortunately it won't be possible to simply change the ObjectIdentifier type because that would break too many applications. If it's not possible to change the type, then most alternatives seem to be somewhat cumbersome. For reference the PR is https://github.com/golang/go/pull/39795. Sebastien On Friday, June 26, 2020 at 10:55:39 AM UTC-7, Sebastien Rosset wrote: > > First apologies for initially bringing up the topic as a github issue > rather than golang-nuts. I am copy-pasting my question here with > @ianlancetaylor > response. > > > A default type value can be specified in C++ templates. I was asking if a > similar construct been considered for go generic type parameters. > Potentially this would make it possible to retrofit existing types without > breaking existing code. > > For example, consider the existing asn1.ObjectIdentifier type which is a > []int. One problem with this type is it's not compliant with the ASN.1 > specification, which states each sub-oid may be an INTEGER of arbitrary > length (e.g. *big.Int). Potentially ObjectIdentifier could be modified to > accept a generic parameter, but that would break a lot of existing code. If > there was a way to specify int is the default parameter value, maybe that > would make it possible to retrofit existing code. > > type SignedInteger interface { > type int, int32, int64, *big.Int > }type ObjectIdentifier(type T SignedInteger) []T// type ObjectIdentifier(type > T SignedInteger=int) []T // `int` would be the default instantiation type. > // New code with generic awareness would compile in go2.var oid1 > ObjectIdentifier(int) = ObjectIdentifier(int){1, 2, 3} > // But existing code would fail to compile:var oid1 ObjectIdentifier = > ObjectIdentifier{1, 2, 3} > > Just to be clear, the above asn1.ObjectIdentifier is just an example. I'm > not saying using generics is the only way or the best way to solve the > ASN.1 compliance issue. > > > > > @sebastien-rosset We have not considered default types for generic type > parameters. The language does not have default values for function > arguments, and it's not obvious why generics would be different. In my > opinion, the ability to make existing code compatible with a package that > adds generics is not a priority. If a package is rewritten to use generics, > it's OK to require existing code to change, or to simply introduce the > generic code using new names. > -- 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/b29e342c-bcd1-4fc3-baf9-431d96120674o%40googlegroups.com.
