[cfe-dev] Allowing '_' as version tuple separator?
Aaron Ballman
aaron at aaronballman.com
Wed Oct 1 09:57:45 PDT 2014
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 and pretty printed by attributes properly (with
appropriate test coverage, of course), I am okay with this.
~Aaron
More information about the cfe-dev
mailing list