Date: Mon, 12 Jul 2021 09:57:50 +0200
On Sun, Jul 11, 2021 at 11:10 PM Jens Maurer via SG16 <sg16_at_[hidden]>
wrote:
> On 11/07/2021 00.12, Tom Honermann via SG16 wrote:
> > We've had several discussions regarding the wording for P2295. Please
> review the latest wording in P2295R4 <https://wg21.link/p2295r4> and, if
> _objections_ (not just desired tweajs) remain, reply to this email to state
> them ahead of the meeting. My intention is to poll forwarding this paper
> with the expectation that core will further tweak the wording pending EWG
> acceptance. The SG16 obligation is to ensure that the intent of the paper
> is clear and that the proposed wording reasonably reflects it; I don't want
> to hold this paper up further unless it is felt that the wording
> misrepresents the intent.
>
> The wording uses both "encoding scheme" and "encoding",
> which might be misconstrued to be different things.
>
Thanks
>
> Please pick a term and use it consistently.
>
> Regarding the uses of "determination"; this word (despite the
> considerable effort on clarifications around it) still feels
> that the compiler determines something (possibly by magic), but
> in reality it is the user that conveys an (out-of-band) assertion
> on the encoding of the source file. It feels English ought to
> have a word or phrase that fits better than "determination".
We do not want to force a user input here, even if we hope that compilers
will provide a sensible interface for users to use.
The compiler can have any heuristic it desires, from "i know it's utf-8
because all files on this system are utf-8" to "reading the tea leaves"
and I thought there was agreement on that now that we have wording to make
bom irrelevant.
I think ascertain is too strong, everything else I can think of is similar
in meaning to determines.
Decides leaves more room for error (which is what we want), but I don't
know if "decides" applies to compilers.
"Assumed in an implementation-defined manner" is more accurate, possibly.
but awful.
> Furthermore, agreed with Hubert's suggestions.
>
> Jens
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
wrote:
> On 11/07/2021 00.12, Tom Honermann via SG16 wrote:
> > We've had several discussions regarding the wording for P2295. Please
> review the latest wording in P2295R4 <https://wg21.link/p2295r4> and, if
> _objections_ (not just desired tweajs) remain, reply to this email to state
> them ahead of the meeting. My intention is to poll forwarding this paper
> with the expectation that core will further tweak the wording pending EWG
> acceptance. The SG16 obligation is to ensure that the intent of the paper
> is clear and that the proposed wording reasonably reflects it; I don't want
> to hold this paper up further unless it is felt that the wording
> misrepresents the intent.
>
> The wording uses both "encoding scheme" and "encoding",
> which might be misconstrued to be different things.
>
Thanks
>
> Please pick a term and use it consistently.
>
> Regarding the uses of "determination"; this word (despite the
> considerable effort on clarifications around it) still feels
> that the compiler determines something (possibly by magic), but
> in reality it is the user that conveys an (out-of-band) assertion
> on the encoding of the source file. It feels English ought to
> have a word or phrase that fits better than "determination".
We do not want to force a user input here, even if we hope that compilers
will provide a sensible interface for users to use.
The compiler can have any heuristic it desires, from "i know it's utf-8
because all files on this system are utf-8" to "reading the tea leaves"
and I thought there was agreement on that now that we have wording to make
bom irrelevant.
I think ascertain is too strong, everything else I can think of is similar
in meaning to determines.
Decides leaves more room for error (which is what we want), but I don't
know if "decides" applies to compilers.
"Assumed in an implementation-defined manner" is more accurate, possibly.
but awful.
> Furthermore, agreed with Hubert's suggestions.
>
> Jens
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
Received on 2021-07-12 02:58:03