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

[Aaron Ballman]

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.

~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
>
>