[cfe-dev] Allowing '_' as version tuple separator?

[Argyrios Kyrtzidis]

> On Oct 1, 2014, at 9:57 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
> 
> On Wed, Oct 1, 2014 at 12:43 PM, jahanian <fjahanian at apple.com <mailto:fjahanian at apple.com>> wrote:
>> 
>> On Oct 1, 2014, at 5:44 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> 
>> On Tue, Sep 30, 2014 at 7:52 PM, jahanian <fjahanian at apple.com> wrote:
>> 
>> Sure. Our primary interest is in their use in availability/deprecated
>> attributes.
>> 
>> An example would be:
>> @protocol P
>> - (void)proto_method
>> __attribute__((availability(macosx,introduced=10_1_0,deprecated=10_2)));
>> @end
>> 
>> Instead of:
>> @protocol P
>> - (void)proto_method
>> __attribute__((availability(macosx,introduced=10.1.0,deprecated=10.2)));
>> @end
>> 
>> But, 'major[.minor[.subminor]]’ are parsed and ‘.’ are checked for,
>> irrespective of their use.
>> So, rather than special case for what we need, I am proposing to allow them
>> everywhere.
>> 
>> 
>> What do you mean by "everywhere?" I'm a bit confused. When I read your
>> original email, I thought you were talking about changing command line
>> argument parsing for places where version numbers matter so that _ and
>> . were interchangeable. Then Doug brought up std::tuple, and now
>> you're talking about availability attributes. A bit more detailed
>> scope information about what you are proposing would be useful. :-)
>> 
>> 
>> Parser::ParseVersionTuple(…) is where 'major[.minor[.subminor]]’ is parsed.
>> I am suggesting to modify it to recognize ‘_’ as separator. So, I propose to
>> change
>> Parser::ParseVersionTuple(…) to also accept ‘major[_minor[_subminor]]’
>> syntax as well.
>> As an example, I brought up an example of versioning in availability
>> attribute and showed
>> how this change will allow 10_1_0 as alternative version. Hope it is clear.
> 
> Thank you for the clarification! So long as VersionTuple remembers
> which form is used (period or underscore) so that it can be printed in
> diagnostics

Hi Aaron,

I don’t think changing the version form that users see in diagnostics is desirable.

The motivating factor for allowing ‘_’ as version form is to get rid of a swath of boilerplate macros that the availability headers go through when there’s a new version, in order to do the conversion and satisfy the availability attribute.
We are proposing that ‘_’ be accepted to vastly simplify the situation but whether the availability attribute got ‘_’ or ‘.’ for defining the version numbers is an underlying detail that should not be exposed to users.
Users have been seeing dot-separated versions in diagnostics forever, suddenly changing the diagnostics to the less aesthetically pleasing underscore-separated version provides no benefit at all and can only lead to minor confusion.

> and pretty printed by attributes properly (with
> appropriate test coverage, of course), I am okay with this.
> 
> ~Aaron
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141003/2bca55e7/attachment.html>