On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset <sros...@gmail.com> wrote:
> @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.

Thanks, understood.

Generics don't solve all problems.  I agree that there seems to be a
way that we could modify generics to solve this particular problem.
But it means introducing an idea that the rest of the language has
decided to reject: default values for arguments.  I don't think it
would be consistent with the language to permit default values for
type arguments when we do not permit default values for non-type
arguments.  While we don't have to be strictly consistent here, I
think we need a good reason to break consistency.  And in the larger
scheme of things I don't think that making it easier to make a
backward compatible change to one specific package, a package that is
not all that widely used, is a good enough reason.

I'm not claiming to have the final word, but that is my opinion.


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 

Reply via email to