By "closed interval" I mean an interval including both bounds (it's my maths showing):
https://en.wikipedia.org/wiki/Interval_(mathematics)

________________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of Charles-Henri Gros via SG15 <sg15_at_lists.isocpp.org>
Sent: Wednesday, May 17, 2023 9:47 AM
To: René Ferdinand Rivera Morell; sg15_at_lists.isocpp.org
Cc: Charles-Henri Gros
Subject: Re: [SG15] P2717R1, EcoIS Introspection

Sorry by "open-ended" I meant "exclusive bound", i.e. use of ().
And by "unpublished version" I mean that, in the usual version schemes, 1.2.3 could easily be published *after* 1.3.0 is out. So, I can't claim to support [1,1.3.0] because that would be implicitly supporting 1.2.3 even though I can't know what it is. If we guarantee monotonic increases, then I remove some of my objections. I still don't think an interval like [1,2) is useful: either 2 has been published, and therefore the last 1.x is known and can be used explicitly, which I think is both clearer and simpler, or 2 has not been published, and I'm claiming support for potential future versions, which is wrong.
If we allow only closed intervals, which I really think we should, and we really care about parsers that do not actually parse the JSON, then I repeat my suggestion of an "a-b" syntax.
If we do only have monotonic increases, then I'm not completely sure I'm on board with the a.b.c versioning scheme. The "small change" vs "large change" distinction doesn't seem worth encoding in the version number if I have to claim exact support anyway.

________________________________________
From: René Ferdinand Rivera Morell <grafikrobot_at_gmail.com>
Sent: Wednesday, May 17, 2023 9:13 AM
To: sg15_at_[hidden]
Cc: Charles-Henri Gros
Subject: Re: [SG15] P2717R1, EcoIS Introspection

On Wed, May 17, 2023 at 10:34 AM Charles-Henri Gros via SG15
<sg15_at_[hidden]> wrote:
>
> Hi!
> Thanks for writing this. I have a few comments (written as I read the document, so not necessarily very well organized):
> > this design follows some basic tenants
> I think you mean "tenets"

Ha, good catch! Thanks.

> > "std:info": "[1,2.5]"
> This interval looks suspiciously like an array (that confused me at first). Perhaps another syntax would be clearer, e.g. "1-2.5". I'm not convinced open-ended intervals are useful; how could I advertise supporting any version less than 2

Open-ended intervals are not allowed. Assuming you mean something like
"[1,]"? Only two kinds of intervals are allowed: inclusive or
exclusive (and combinations thereof). For saying that you only
implement all versions less than 2 you would have to specify the
starting point also. I.e. "[0,2)".

>, when such versions may not have been published yet?

Not sure how you would be able to write a tool that claims to support
some future unpublished standard. I can understand supporting
in-progress versions of the standard though. But those could use some
"next" prospective version number (like 9999.0.0).

> Also, it may be useful to allow specifying multiple intervals. Thinking more about it, I don't think specifying a syntax for the contents of a string is a good idea in a format like JSON that allows structured data. So, instead, may I suggest
> { "min": "1", "max": "1.4" }
> [ { "min": "1", "max": "1.4" }, "2.0" ]
> Parsing is hard, I already have a JSON parser, let it do the work.
> In general, any interval that may include a not-published version seems suspicious to me, and that includes any interval that's not of the form [a.b.c,a.b.d]. I think I would prefer an explicit list of supported versions (which again can be a JSON array). I don't think we'll ever have so many versions (that one tool would be compatible with) that this becomes an issue. This also simplifies version matching.
> This might not follow the "concise" tenet, but maybe I don't agree with that tenet. We're not going to be limited by bandwidth here, and even a human should be able to find what they need easily enough.

I'll see about adding some of this to the paper..

The main reason for the tenet, and the concise version range, is to
make it easier for tools that may not have a full JSON parser to do
some simple regex parsing. Although that's not a big reason now that
the --std-decl option is gone in favor of the min/full levels. But one
thing that having the concise syntax does is make it way less verbose
to try and encode inclusive/exclusive ranges. Another aspect to
consider is that a *human* is likely going to be typing those ranges
in source code. But, yes, I see using additional json objects/fields
could be useful.

Don't think I'll have time to write anything on this aspect before
tonight. And I'd like sg15 to discuss it more before I go change the
wording. Definitely a topic for an sg15 meeting :-)

> ^[a-z_]+(:[a-z_]+)+$
> Any rationale for not allowing 0-9A-Z? (which is what one would expect of an identifier in a C++ context). I don't necessarily disagree with the decision, but it would be nice to explain this apparent discrepancy.

Keeping things lower-case avoids case mistakes. While I can see having
numbers could be useful. It might be better to disallow them to avoid
them being used to create alternate versioning instead of using the
real version numbers. Can you think of a use case to need numbers in
the names?


--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything -- No Supone Nada
-- Robot Dreams - https://urldefense.com/v3/__http://robot-dreams.net__;!!A4F2R9G_pg!byQSjDA-yU9wKjW7CzicwiCH3y7FHPdZ5yZ36Lnk3tArlyXCTE00hJVyGt28RTDvF7r5ELwM0KGoQ6Qm6vT-KVcyT-rlhg$
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg15__;!!A4F2R9G_pg!aC7M4rcEt0P0SzcUEpVT4b_iHQECyZn4J2HC9-TzQ4Cz35cpQEkTx6e3v_cyrO_ftq-UXHniWfxKCoId$