As an aside, the most common use of the encoding/asn1 package is most 
likely crypto/x509. x509. Certificate exposes public fields that use the 
asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of 
applications, such as for TLS connection management.

On Friday, June 26, 2020 at 12:04:09 PM UTC-7, Sebastien Rosset wrote:
> sure, thank you. I will go through the PR review process for asn1 and 
> x509, maybe some good ideas will come up. 
> Sebastien 
> On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote:
>> On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset <> 
>> 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 
>> 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. 
>> 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 view this discussion on the web visit

Reply via email to