Date: Wed, 17 May 2023 15:34:24 +0000
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"
> "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, when such versions may not have been published yet? 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.
^[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.
________________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of René Ferdinand Rivera Morell via SG15 <sg15_at_[hidden]>
Sent: Tuesday, May 16, 2023 9:11 PM
To: ISO C++ Tooling Study Group
Cc: René Ferdinand Rivera Morell
Subject: [SG15] P2717R1, EcoIS Introspection
Just finished with the next revision of the tool introspection paper.
Two big changes:
* Simplified the interface by removing bounded query of implementation support.
* Added hopefully full wording.
Here's a preview of it:
<https://urldefense.com/v3/__https://raw.githack.com/grafikrobot/papers/main/wg21/ecosystem_is_introspect/ecosystem_is_introspect_P2717R1.html__;!!A4F2R9G_pg!aFll2ItMYZFPHzT_P_SAl1tpOIpzZY6tTxMeSy_As-ruU_e2Cf9FFCdr-eboBFtVvOey6vLO2WDuQh65$ >
I'll add it to the "to be mailed" queue in about 24 hours. Would
welcome commentary and proofreading before then.
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"
> "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, when such versions may not have been published yet? 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.
^[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.
________________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of René Ferdinand Rivera Morell via SG15 <sg15_at_[hidden]>
Sent: Tuesday, May 16, 2023 9:11 PM
To: ISO C++ Tooling Study Group
Cc: René Ferdinand Rivera Morell
Subject: [SG15] P2717R1, EcoIS Introspection
Just finished with the next revision of the tool introspection paper.
Two big changes:
* Simplified the interface by removing bounded query of implementation support.
* Added hopefully full wording.
Here's a preview of it:
<https://urldefense.com/v3/__https://raw.githack.com/grafikrobot/papers/main/wg21/ecosystem_is_introspect/ecosystem_is_introspect_P2717R1.html__;!!A4F2R9G_pg!aFll2ItMYZFPHzT_P_SAl1tpOIpzZY6tTxMeSy_As-ruU_e2Cf9FFCdr-eboBFtVvOey6vLO2WDuQh65$ >
I'll add it to the "to be mailed" queue in about 24 hours. Would
welcome commentary and proofreading before then.
-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - https://urldefense.com/v3/__http://robot-dreams.net__;!!A4F2R9G_pg!aFll2ItMYZFPHzT_P_SAl1tpOIpzZY6tTxMeSy_As-ruU_e2Cf9FFCdr-eboBFtVvOey6vLO2WXVpvdm$ _______________________________________________ SG15 mailing list SG15_at_[hidden] https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg15__;!!A4F2R9G_pg!aFll2ItMYZFPHzT_P_SAl1tpOIpzZY6tTxMeSy_As-ruU_e2Cf9FFCdr-eboBFtVvOey6vLO2ew-HggG$
Received on 2023-05-17 15:34:33