Date: Thu, 2 Jul 2020 15:48:37 +0000
[Tom]
* The goal isn't to win; it is to have a clear specification
Thank you!
-- Gaby
From: Core <core-bounces_at_[hidden]> On Behalf Of Tom Honermann via Core
Sent: Wednesday, July 1, 2020 11:02 PM
To: Corentin Jabot <corentinjabot_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]>; SG16 <sg16_at_[hidden]>; C++ Core Language Working Group <core_at_[hidden]>
Subject: Re: [isocpp-core] [SG16] New draft revision: D2029R2 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals)
On 7/2/20 1:40 AM, Corentin Jabot wrote:
On Thu, Jul 2, 2020, 06:25 Tom Honermann <tom_at_honermann.net<mailto:tom_at_[hidden]>> wrote:
On 7/1/20 3:23 AM, Corentin Jabot wrote:
On Wed, Jul 1, 2020, 00:28 Jens Maurer via Core <core_at_[hidden]<mailto:core_at_[hidden]>> wrote:
On 30/06/2020 06.15, Corentin Jabot via SG16 wrote:
> No, especially wide multi characters that are simply not a thing, let's not make them one.
I don't follow. In the status quo working draft, we have in [lex.ccon] p5
after the note:
"The value of a wide-character literal containing multiple c-char s is implementation-defined."
I would rather it doesn't have a name, especially not one that makes it look like it behaves like multi character literals, which it doesn't (not an int, value computed differently).
Corentin, I don't understand this statement about multicharacter literals having different behavior. Yes, ordinary and wide multicharacter literals have different types. So do ordinary and wide character literals. For both kinds of multicharacter literals, the value is implementation-defined; I don't know where this claim that they are computed differently comes from.
Look at how they are implemented in practice, and look at usages ( or lack thereof in the case of wide characters with multiple c-char).
Implementers just pick one one of the c-char and encode that.
That is exactly the reason these are specified to be conditionally-supported with implementation-defined values.
As such I would like it if core would consider keeping the above sentence below the table ( same thing for what tom calls conditional characters literals - both of them).
Giving names to things tends to make them feel more important or intended, which I think we should avoid in this case.
I disagree. Names are given to make things easier to refer to and discuss. These different behaviors are clearly intended. Giving something a name is not synonymous with endorsing it.
I am afraid the only way I will win this this is to convince ewg to make that ill-formed, isn't it?
The goal isn't to win; it is to have a clear specification. But should a proposal to make them ill-formed be adopted, I would shed no tears ;)
(I think it would not be unreasonable to propose removing these from the standard because, arguably, the standard should not specify anything that is conditionally-supported with implementation-defined behavior (unless the implementation-defined behavior is selected from a set of options specified by the standard; which isn't the case here)).
Tom.
Tom.
Jens
_______________________________________________
Core mailing list
Core_at_[hidden]<mailto:Core_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fcore&data=02%7C01%7Cgdr%40microsoft.com%7C3f790270ce4e4bde301908d81e4d958e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637292665925470527&sdata=ZH9yHXdGwcqAWDzxRehN29%2B0Wym5dZdB5tXzj7PYfUE%3D&reserved=0>
Link to this post: http://lists.isocpp.org/core/2020/06/9487.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2020%2F06%2F9487.php&data=02%7C01%7Cgdr%40microsoft.com%7C3f790270ce4e4bde301908d81e4d958e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637292665925480522&sdata=G8j2fQVHDXRNkii1vKmFkWI1Liqv1FeZBJ8hOADh9D8%3D&reserved=0>
* The goal isn't to win; it is to have a clear specification
Thank you!
-- Gaby
From: Core <core-bounces_at_[hidden]> On Behalf Of Tom Honermann via Core
Sent: Wednesday, July 1, 2020 11:02 PM
To: Corentin Jabot <corentinjabot_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]>; SG16 <sg16_at_[hidden]>; C++ Core Language Working Group <core_at_[hidden]>
Subject: Re: [isocpp-core] [SG16] New draft revision: D2029R2 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals)
On 7/2/20 1:40 AM, Corentin Jabot wrote:
On Thu, Jul 2, 2020, 06:25 Tom Honermann <tom_at_honermann.net<mailto:tom_at_[hidden]>> wrote:
On 7/1/20 3:23 AM, Corentin Jabot wrote:
On Wed, Jul 1, 2020, 00:28 Jens Maurer via Core <core_at_[hidden]<mailto:core_at_[hidden]>> wrote:
On 30/06/2020 06.15, Corentin Jabot via SG16 wrote:
> No, especially wide multi characters that are simply not a thing, let's not make them one.
I don't follow. In the status quo working draft, we have in [lex.ccon] p5
after the note:
"The value of a wide-character literal containing multiple c-char s is implementation-defined."
I would rather it doesn't have a name, especially not one that makes it look like it behaves like multi character literals, which it doesn't (not an int, value computed differently).
Corentin, I don't understand this statement about multicharacter literals having different behavior. Yes, ordinary and wide multicharacter literals have different types. So do ordinary and wide character literals. For both kinds of multicharacter literals, the value is implementation-defined; I don't know where this claim that they are computed differently comes from.
Look at how they are implemented in practice, and look at usages ( or lack thereof in the case of wide characters with multiple c-char).
Implementers just pick one one of the c-char and encode that.
That is exactly the reason these are specified to be conditionally-supported with implementation-defined values.
As such I would like it if core would consider keeping the above sentence below the table ( same thing for what tom calls conditional characters literals - both of them).
Giving names to things tends to make them feel more important or intended, which I think we should avoid in this case.
I disagree. Names are given to make things easier to refer to and discuss. These different behaviors are clearly intended. Giving something a name is not synonymous with endorsing it.
I am afraid the only way I will win this this is to convince ewg to make that ill-formed, isn't it?
The goal isn't to win; it is to have a clear specification. But should a proposal to make them ill-formed be adopted, I would shed no tears ;)
(I think it would not be unreasonable to propose removing these from the standard because, arguably, the standard should not specify anything that is conditionally-supported with implementation-defined behavior (unless the implementation-defined behavior is selected from a set of options specified by the standard; which isn't the case here)).
Tom.
Tom.
Jens
_______________________________________________
Core mailing list
Core_at_[hidden]<mailto:Core_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fcore&data=02%7C01%7Cgdr%40microsoft.com%7C3f790270ce4e4bde301908d81e4d958e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637292665925470527&sdata=ZH9yHXdGwcqAWDzxRehN29%2B0Wym5dZdB5tXzj7PYfUE%3D&reserved=0>
Link to this post: http://lists.isocpp.org/core/2020/06/9487.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2020%2F06%2F9487.php&data=02%7C01%7Cgdr%40microsoft.com%7C3f790270ce4e4bde301908d81e4d958e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637292665925480522&sdata=G8j2fQVHDXRNkii1vKmFkWI1Liqv1FeZBJ8hOADh9D8%3D&reserved=0>
Received on 2020-07-02 10:52:41