Date: Thu, 29 Apr 2021 13:39:09 -0400
On 4/29/21 11:37 AM, Corentin wrote:
>
>
> On Thu, Apr 29, 2021, 17:32 Tom Honermann <tom_at_[hidden]
> <mailto:tom_at_[hidden]>> wrote:
>
> On 4/29/21 6:39 AM, Peter Brett via SG16 wrote:
>>
>> Hi Corentin,
>>
>> I think this is a big improvement!
>>
>> Does anyone know what “physical” means in [lex.phases]:1? I feel
>> like we could remove both occurrences of “physical” from this
>> paragraph without any normative effect.
>>
> I don't have a reference to cite, but I interpret this as
> follows. If we think of the standard as an abstract
> specification, the use of "physical" is what connects it to
> something that exists in the real world. This allows the
> specification to be applied to, for example, code written on a
> napkin or a blackboard. I won't lose any sleep over dropping
> "physical" here, but I can imagine a situation in which the ISO
> has some rule that specifications may not be completely abstract;
> that they have to describe something "real". I have no idea if
> any such rule exists.
>
>
> I suggested previously using input (character, file).
> You'll seemed to prefer it being a separate paper. Which i tend to
> agree with.
I see the name used here (physical, source, input, etc...) as purely a
core specification issue. I don't personally think it is worth a
separate paper; changing that in this paper seems fine to me as it
doesn't affect any normative behavior and doesn't require SG16 input.
If the CWG likes it, great, if not, they'll tell you to change it back
or to something else as part of their review.
Tom.
> Tom.
>
>> There is an obvious incomplete merge with P2314, in that the
>> current P2295 wording suggests that UCN doesn’t occur for UTF-8
>> source files. Just to clarify this, please could we insert a
>> paragraph break before “Any source file character…”?
>>
>> I don’t have any concerns about forwarding this paper to EWG in
>> its current form.
>>
>> Best regards,
>>
>> Peter
>>
>> *From:*SG16 <sg16-bounces_at_[hidden]>
>> <mailto:sg16-bounces_at_[hidden]> *On Behalf Of *Corentin
>> via SG16
>> *Sent:* 29 April 2021 08:35
>> *To:* SG16 <sg16_at_[hidden]> <mailto:sg16_at_[hidden]>
>> *Cc:* Corentin <corentin.jabot_at_[hidden]>
>> <mailto:corentin.jabot_at_[hidden]>
>> *Subject:* [SG16] P2295R3 Support for UTF-8 as a portable source
>> file encoding
>>
>> EXTERNAL MAIL
>>
>> Per request in yesterday's meeting,
>>
>> here is P2295R3 Support for UTF-8 as a portable source file encoding.
>>
>> I am looking forward to your feedback
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2295r3.pdf
>> <https://urldefense.com/v3/__http:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2295r3.pdf__;!!EHscmS1ygiU1lA!XaO4EGAyt6UeI1vxk8b0nQ_eprHj_DnOwoz0W7Ql_YPrpGZJkaTnisiu138yiQ$>
>>
>>
>
>
>
> On Thu, Apr 29, 2021, 17:32 Tom Honermann <tom_at_[hidden]
> <mailto:tom_at_[hidden]>> wrote:
>
> On 4/29/21 6:39 AM, Peter Brett via SG16 wrote:
>>
>> Hi Corentin,
>>
>> I think this is a big improvement!
>>
>> Does anyone know what “physical” means in [lex.phases]:1? I feel
>> like we could remove both occurrences of “physical” from this
>> paragraph without any normative effect.
>>
> I don't have a reference to cite, but I interpret this as
> follows. If we think of the standard as an abstract
> specification, the use of "physical" is what connects it to
> something that exists in the real world. This allows the
> specification to be applied to, for example, code written on a
> napkin or a blackboard. I won't lose any sleep over dropping
> "physical" here, but I can imagine a situation in which the ISO
> has some rule that specifications may not be completely abstract;
> that they have to describe something "real". I have no idea if
> any such rule exists.
>
>
> I suggested previously using input (character, file).
> You'll seemed to prefer it being a separate paper. Which i tend to
> agree with.
I see the name used here (physical, source, input, etc...) as purely a
core specification issue. I don't personally think it is worth a
separate paper; changing that in this paper seems fine to me as it
doesn't affect any normative behavior and doesn't require SG16 input.
If the CWG likes it, great, if not, they'll tell you to change it back
or to something else as part of their review.
Tom.
> Tom.
>
>> There is an obvious incomplete merge with P2314, in that the
>> current P2295 wording suggests that UCN doesn’t occur for UTF-8
>> source files. Just to clarify this, please could we insert a
>> paragraph break before “Any source file character…”?
>>
>> I don’t have any concerns about forwarding this paper to EWG in
>> its current form.
>>
>> Best regards,
>>
>> Peter
>>
>> *From:*SG16 <sg16-bounces_at_[hidden]>
>> <mailto:sg16-bounces_at_[hidden]> *On Behalf Of *Corentin
>> via SG16
>> *Sent:* 29 April 2021 08:35
>> *To:* SG16 <sg16_at_[hidden]> <mailto:sg16_at_[hidden]>
>> *Cc:* Corentin <corentin.jabot_at_[hidden]>
>> <mailto:corentin.jabot_at_[hidden]>
>> *Subject:* [SG16] P2295R3 Support for UTF-8 as a portable source
>> file encoding
>>
>> EXTERNAL MAIL
>>
>> Per request in yesterday's meeting,
>>
>> here is P2295R3 Support for UTF-8 as a portable source file encoding.
>>
>> I am looking forward to your feedback
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2295r3.pdf
>> <https://urldefense.com/v3/__http:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2295r3.pdf__;!!EHscmS1ygiU1lA!XaO4EGAyt6UeI1vxk8b0nQ_eprHj_DnOwoz0W7Ql_YPrpGZJkaTnisiu138yiQ$>
>>
>>
>
Received on 2021-04-29 12:39:12