Date: Mon, 23 Aug 2021 17:23:54 -0700
---------- Forwarded message ---------
From: Hubert Tong via Ext <ext_at_[hidden]>
Date: Tue, Jul 27, 2021 at 8:47 PM
Subject: [isocpp-ext] Feedback on P1875/P2066: Transactional Memory Lite TS
To: Jens Maurer <Jens.Maurer_at_[hidden]>, SG1 concurrency and parallelism <
parallel_at_[hidden]>, Evolution Working Group mailing list <
ext_at_[hidden]>
Cc: Hubert Tong <hubert.reinterpretcast_at_[hidden]>
Question about the design:
Has there been any indication that an `if consteval`-like facility would be
useful for providing alternative implementations?
Feedback on the wording paper:
What is the bullet re:
- a function call whose postfix-expression does not name a function
really meant to do?
I can understand calls via function pointers or surrogate call functions
being included (for falling under potential UB) by the bullet, but I don't
see how the wording makes clear that it is meant to apply after overload
resolution (including any relevant template argument deduction) and any
applicable transformation for surrogate call operators.
Also, the revision history has this:
Nearly all standard library functions may be used inside an atomic block;
any other function is restricted to compiler-visible.
But the wording does not exempt library functions from the
implementation-defined, possibly UB case; abstractly, I don't think the
library functions are required to be inline functions with a reachable
definition.
Additionally, the wording is not particularly clear about the effect if a
user program does potentially run-time evaluate, in an atomic block,
library functions for which permission is being withheld. If the operative
words should be "ill-formed, no diagnostic required", then let the paper
have those words (or perhaps LWG prefers some sort of precondition-based
method of implementing IFNDR).
Lastly, I would like specific consideration of `raise` and `system` as
library functions that are not permitted for potential run-time evaluation
in an atomic block.
_______________________________________________
Ext mailing list
Ext_at_[hidden]
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
Link to this post: http://lists.isocpp.org/ext/2021/07/17094.php
From: Hubert Tong via Ext <ext_at_[hidden]>
Date: Tue, Jul 27, 2021 at 8:47 PM
Subject: [isocpp-ext] Feedback on P1875/P2066: Transactional Memory Lite TS
To: Jens Maurer <Jens.Maurer_at_[hidden]>, SG1 concurrency and parallelism <
parallel_at_[hidden]>, Evolution Working Group mailing list <
ext_at_[hidden]>
Cc: Hubert Tong <hubert.reinterpretcast_at_[hidden]>
Question about the design:
Has there been any indication that an `if consteval`-like facility would be
useful for providing alternative implementations?
Feedback on the wording paper:
What is the bullet re:
- a function call whose postfix-expression does not name a function
really meant to do?
I can understand calls via function pointers or surrogate call functions
being included (for falling under potential UB) by the bullet, but I don't
see how the wording makes clear that it is meant to apply after overload
resolution (including any relevant template argument deduction) and any
applicable transformation for surrogate call operators.
Also, the revision history has this:
Nearly all standard library functions may be used inside an atomic block;
any other function is restricted to compiler-visible.
But the wording does not exempt library functions from the
implementation-defined, possibly UB case; abstractly, I don't think the
library functions are required to be inline functions with a reachable
definition.
Additionally, the wording is not particularly clear about the effect if a
user program does potentially run-time evaluate, in an atomic block,
library functions for which permission is being withheld. If the operative
words should be "ill-formed, no diagnostic required", then let the paper
have those words (or perhaps LWG prefers some sort of precondition-based
method of implementing IFNDR).
Lastly, I would like specific consideration of `raise` and `system` as
library functions that are not permitted for potential run-time evaluation
in an atomic block.
_______________________________________________
Ext mailing list
Ext_at_[hidden]
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
Link to this post: http://lists.isocpp.org/ext/2021/07/17094.php
Received on 2021-08-23 19:24:07