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

[Argyrios Kyrtzidis]

> On Oct 3, 2014, at 10:09 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
> 
> On Fri, Oct 3, 2014 at 1:04 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com <mailto:kyrtzidis 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.
>> 
>> 
>> 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.
> 
> I can live with that reasoning in this case, but I have a preference
> for always showing the user what they wrote in diagnostics to reduce
> confusion. It is confusing when you get a diagnostic that reads "Blah
> blah blah is wrong" and you go "but I didn't write blah blah blah, so
> what is the compiler complaining about?”

I see your point, but in this particular case, writing the version with underscore instead of dots is a very uncommon case (I mean we just introduced it ;-) so it will be a conscious choice for convenience purposes (compared to the dot form) not because the API author really wants to show underscores in the diagnostics.

> 
> ~Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141003/9fd6c958/attachment.html>