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

[Aaron Ballman]

On Fri, Oct 3, 2014 at 1:04 PM, Argyrios Kyrtzidis <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?"

~Aaron