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

[jahanian]

On Oct 3, 2014, at 9:52 AM, Aaron Ballman <aaron at aaronballman.com> wrote:

> On Fri, Oct 3, 2014 at 12:26 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>> 
>> 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> 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.
> 
> That's reasonable to me, thank you for the explanation!
> 
>> 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.
> 
> Agreed, for your use case. A bit less agreed for the use case where a
> user writes the version tuple manually using an underscore, and it
> gets printed using a period. But I think that's far less likely to be
> an issue than the macro use case.
> 
> We have ways of telling whether something was written due to macros or
> not, so this is solvable, but likely not at all worth the effort right
> now. However, the pretty printing is still problematic. I think the
> code should round-trip, even when they are functionally equivalent.

I will look into the pretty printing of the declaration for underscore as promised. We have another
problem that in the case of Objective-C methods, no availability attribute is pretty printed at all.
- Fariborz

> 
> ~Aaron
> 
>> 
>> 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
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>>