Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Robert Engels
Yes I did. Sorry all. 

> On Jun 26, 2020, at 7:42 PM, Sebastien Rosset  wrote:
> 
> 
> Did you reply to the wrong thread?
> 
>> On Friday, June 26, 2020 at 3:09:42 PM UTC-7, Robert Engels wrote:
>> What about an option to disable the signal on the thread as it crosses the 
>> CGo boundary? This seems better than disabling the async preemption entirely?
>> 
 On Jun 26, 2020, at 4:45 PM, Sebastien Rosset  wrote:
 
>>> 
>>> 
>>> Below are the publicly exposed asn1.ObjectIdentifier fields in the 
>>> golang/go repo. It has fairly limited exposure,
>>> but I'm sure some people will argue it's too much (maybe ok in go 2.x but 
>>> not 1.x?).
>>> encoding/asn1:
>>> My guess is this would be primarily used by SNMP applications such as 
>>> https://github.com/soniah/gosnmp/search?q=asn1_q=asn1
>>> crypto/x509/pkix package has 4 exported fields using asn1.ObjectIdentifier
>>> crypto/x509 package:
>>>  ECDSA keys
>>>  Used in the x509.Certificate struct:
>>> // A Certificate represents an X.509 certificate.
>>> type Certificate struct {
>>>   ...
>>>   UnhandledCriticalExtensions []asn1.ObjectIdentifier
>>>   UnknownExtKeyUsage []asn1.ObjectIdentifier
>>>   PolicyIdentifiers []asn1.ObjectIdentifier
>>> }
>>> 
>>> I doubt there are many applications that actually inspect these 3 fields.
>>> 
>>> 
>>> 
 On Friday, June 26, 2020 at 12:53:43 PM UTC-7, Sebastien Rosset wrote:
 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 
>> > 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. 
>> 
>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/39bf626a-ed31-4c89-bc0f-a685927e7046o%40googlegroups.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/8a0157a1-aea2-489e-99ce-42e5c135a61do%40googlegroups.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 

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
Did you reply to the wrong thread?

On Friday, June 26, 2020 at 3:09:42 PM UTC-7, Robert Engels wrote:
>
> What about an option to disable the signal on the thread as it crosses the 
> CGo boundary? This seems better than disabling the async preemption 
> entirely?
>
> On Jun 26, 2020, at 4:45 PM, Sebastien Rosset  > wrote:
>
> 
>
> Below are the publicly exposed asn1.ObjectIdentifier fields in the 
> golang/go repo. It has fairly limited exposure,
> but I'm sure some people will argue it's too much (maybe ok in go 2.x but 
> not 1.x?).
>
>1. encoding/asn1:
>   1. My guess is this would be primarily used by SNMP applications 
>   such as 
>   https://github.com/soniah/gosnmp/search?q=asn1_q=asn1
>   2. crypto/x509/pkix package has 4 exported fields using asn1.
>ObjectIdentifier
>3. crypto/x509 package:
>   1. ECDSA keys
>   2. Used in the x509.Certificate struct:
>
> // A Certificate represents an X.509 certificate.
>
> type Certificate struct {
>
> ...
>
> UnhandledCriticalExtensions []asn1.ObjectIdentifier
>
> UnknownExtKeyUsage []asn1.ObjectIdentifier
>
> PolicyIdentifiers []asn1.ObjectIdentifier
>
> }
>
>
> I doubt there are many applications that actually inspect these 3 fields.
>
>
>
> On Friday, June 26, 2020 at 12:53:43 PM UTC-7, Sebastien Rosset wrote:
>>
>> 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 
 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. 

 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/39bf626a-ed31-4c89-bc0f-a685927e7046o%40googlegroups.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/8a0157a1-aea2-489e-99ce-42e5c135a61do%40googlegroups.com.


Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Robert Engels
What about an option to disable the signal on the thread as it crosses the CGo 
boundary? This seems better than disabling the async preemption entirely?

> On Jun 26, 2020, at 4:45 PM, Sebastien Rosset  wrote:
> 
> 
> 
> Below are the publicly exposed asn1.ObjectIdentifier fields in the golang/go 
> repo. It has fairly limited exposure,
> but I'm sure some people will argue it's too much (maybe ok in go 2.x but not 
> 1.x?).
> encoding/asn1:
> My guess is this would be primarily used by SNMP applications such as 
> https://github.com/soniah/gosnmp/search?q=asn1_q=asn1
> crypto/x509/pkix package has 4 exported fields using asn1.ObjectIdentifier
> crypto/x509 package:
>  ECDSA keys
>  Used in the x509.Certificate struct:
> // A Certificate represents an X.509 certificate.
> type Certificate struct {
>   ...
>   UnhandledCriticalExtensions []asn1.ObjectIdentifier
>   UnknownExtKeyUsage []asn1.ObjectIdentifier
>   PolicyIdentifiers []asn1.ObjectIdentifier
> }
> 
> I doubt there are many applications that actually inspect these 3 fields.
> 
> 
> 
>> On Friday, June 26, 2020 at 12:53:43 PM UTC-7, Sebastien Rosset wrote:
>> 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 
 > 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. 
 
 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/39bf626a-ed31-4c89-bc0f-a685927e7046o%40googlegroups.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/A8750105-438D-415C-965B-B74578135D53%40ix.netcom.com.


Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset

Below are the publicly exposed asn1.ObjectIdentifier fields in the 
golang/go repo. It has fairly limited exposure,
but I'm sure some people will argue it's too much (maybe ok in go 2.x but 
not 1.x?).

   1. encoding/asn1:
  1. My guess is this would be primarily used by SNMP applications such 
  as https://github.com/soniah/gosnmp/search?q=asn1_q=asn1
  2. crypto/x509/pkix package has 4 exported fields using asn1.
   ObjectIdentifier
   3. crypto/x509 package:
  1. ECDSA keys
  2. Used in the x509.Certificate struct:
   
// A Certificate represents an X.509 certificate.

type Certificate struct {

...

UnhandledCriticalExtensions []asn1.ObjectIdentifier

UnknownExtKeyUsage []asn1.ObjectIdentifier

PolicyIdentifiers []asn1.ObjectIdentifier

}


I doubt there are many applications that actually inspect these 3 fields.



On Friday, June 26, 2020 at 12:53:43 PM UTC-7, Sebastien Rosset wrote:
>
> 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 
>>> 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. 
>>>
>>> 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/39bf626a-ed31-4c89-bc0f-a685927e7046o%40googlegroups.com.


Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Ian Lance Taylor
On Fri, Jun 26, 2020 at 12:54 PM Sebastien Rosset  wrote:
>
> 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.

True, but will those packages be affected by a change in the encoding/asn1 API?

When I said that the package was not widely used I should have said
that not many other packages import it, and thus not many other
packages are affected by any changes.  I shouldn't have implied that
only a few Go programs import it at all.

Ian


> 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 
>>> > 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.
>>>
>>> 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/a34c936f-b68e-4f63-aad2-47c0869f71e0o%40googlegroups.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/CAOyqgcUzN4S%3Dm2Hr8kmStcLNe7HsDA62mJkcdg8-%2B-Xk7dHG8w%40mail.gmail.com.


Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
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 
>> 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. 
>>
>> 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/a34c936f-b68e-4f63-aad2-47c0869f71e0o%40googlegroups.com.


Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
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 
> 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. 
>
> 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/551cacb5-8bef-439d-bb17-2fc8d6b8c357o%40googlegroups.com.


Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Ian Lance Taylor
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 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.

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/CAOyqgcWD3wYG13pNUociK6vwHOsCH5X_05b9wEhxKcDu8_o0MQ%40mail.gmail.com.