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

[Aaron Ballman]

On Fri, Oct 3, 2014 at 12:54 PM, jahanian <fjahanian at apple.com> wrote:
>
> 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.

That seems like a rather higher priority than the contents of the
attribute. ;-) Good catch, and thank you for working on this!

~Aaron