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

[Argyrios Kyrtzidis]

> 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 <mailto: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.

Glad you agree and thanks for your feedback!

> 
> We have ways of telling whether something was written due to macros or
> not, so this is solvable,

This may be a bit bike-shedding at this point but changing whether a diagnostic prints dot-version or underscore-version based on whether the version text came from a macro or not, seems like a bit inconsistent and confusing rule to me.
The rule “you can define the version for the availability attribute with dots or underscores, but diagnostics always print dots as the canonical form” seems better to me.

> 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.
> 
> ~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 <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/f275f83b/attachment.html>