14:10:53 From Robin Rowe to Everyone:
	David, please share link to your upcoming platform talk.
14:11:08 From Robin Rowe to Everyone:
	I meant Guy Davidson,
14:11:19 From Guy Davidson (he/him) {GB} to Everyone:
	I don't believe it will be recorded.
14:11:35 From Guy Davidson (he/him) {GB} to Everyone:
	However, I may try to give it again in an environment where it WILL be recorded.
14:11:38 From Robin Rowe to Everyone:
	Is there an announcement?
14:13:20 From Robin Rowe to Everyone:
	Can I at least get a summary or outline of platform talk?
14:13:43 From Guy Davidson (he/him) {GB} to Everyone:
	There is no announcement, it is a private conference.
14:18:27 From Robin Rowe to Everyone:
	When I try https://cppto.jp/ it says no access. Where is CFP?
14:24:56 From Guy Davidson (he/him) {GB} to Everyone:
	Which conference are you thinking of?
14:26:47 From Robin Rowe to Everyone:
	https://isocpp.org/files/papers/N4946.pdf
14:28:40 From Guy Davidson (he/him) {GB} to Everyone:
	That conference has been cancelled due to unavailability of rooms.
14:29:50 From Patrice Roy to Everyone:
	Title 1.5: the «with» is misspelled
14:39:16 From John McFarlane to Everyone:
	I believe R5 is attached to meeting invite.
14:39:17 From Andre Kostur to Everyone:
	Michael did attach a copy to his email.
14:44:48 From Robin Rowe to Everyone:
	https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html
	
	P2544 makes presents a convincing argument that exceptions are unusable in high core count platforms, are hopeless. Bjarne created exceptions so batch C++ programs would terminate cleanly on error instead of crashing. In real-time and low latency systems, where we hope to never terminate and don't want the global lock that throwing an exception will implicitly call, we avoid or disable exceptions. In low latency gaming, embedded or financial systems, we don't need to "fix" exceptions, in my opinion, because we don't have exceptions to fix. P2544 doesn't address the obvious no-exceptions fix for its do_sqrt() example, to return bool instead of void.
14:48:20 From Brett to Everyone:
	so will you enforce traits to make sure that only double or integer is being used?
14:48:48 From Brett to Everyone:
	I see that Executors has this implemented
14:51:04 From John McFarlane to Everyone:
	Yeah, is_arithmetic is a concern.
14:52:41 From Patrice Roy to Everyone:
	Isn't «DistanceValue» a strange name for a type (or type constraint)? Maybe it's just me...
15:00:45 From Robin Rowe to Everyone:
	Just wondering, why not use the typical way of removing exceptions, to return bool and modify by reference as an arg, instead of creating and returning a value from within a function.
15:02:22 From Paul Bendixen to Everyone:
	Or perhaps even use expected or something like it?
15:02:32 From Robin Rowe to Everyone:
	It makes no sense to me when I see a void function that has a throw in it.
15:02:52 From Bryan St. Amour {CA - MayStreet} to Everyone:
	can't use mandates for the non-negative return value.
15:03:28 From Bryan St. Amour {CA - MayStreet} to Everyone:
	that would have to be a precondition, or something else
15:03:42 From Bryan St. Amour {CA - MayStreet} to Everyone:
	(sorry for the late comment)
15:04:19 From Michael Caisse (Intel) to Everyone:
	Thank you Patrice for asking the out-arg question.
15:09:14 From Patrice Roy to Everyone:
	expected would probably be a better fit than bool
15:11:04 From Michael Caisse (Intel) to Everyone:
	Reacted to "expected would pro..." with 👍
15:11:32 From Bryan St. Amour {CA - MayStreet} to Everyone:
	Would you expect (sorry) the return type of it to be std::excepted<OuterContainer, E> ?
15:11:52 From Bryan St. Amour {CA - MayStreet} to Everyone:
	because that might incur more allocations. With the ref-parameter, I can re-use my buffer.
15:14:36 From Michael Caisse (Intel) to Everyone:
	Using std::expected<void, E> would be good. It allows composition.
15:14:55 From Bryan St. Amour {CA - MayStreet} to Everyone:
	Reacted to "Using std::expecte..." with 👍
15:15:37 From Patrice Roy to Everyone:
	I haven't played with the graph library (BGL or currently proposed); I was more wondering about conveying the reason for failure (since the function takes an OuterContainer& as argument, maybe there could be an expected<OuterContainer&,Reason> or somesuch but I don't want to suggest something without having thought about the consequences for the API (dangling risks and all). Michael's expected<void,E> makes sense as far as I can see but it's something to think about
15:35:03 From Michael Caisse (Intel) to Everyone:
	the screen share has gone black for me. Other people still see ok?
15:35:13 From Patrice Roy to Everyone:
	I see well
15:35:17 From Brett to Everyone:
	See it well
15:35:34 From Andre Kostur to Everyone:
	Reacted to "I see well" with ➕
15:58:15 From Patrice Roy to Everyone:
	Using concepts to formalize glossary terms seems like an interesting approach
15:58:25 From Henry Miller to Everyone:
	The important thing is someone doesn't lock in data structures (ABI) that are not compatible with algorithms that get delayed to cpp-next.
16:01:01 From Patrice Roy to Everyone:
	I will do Tokyo remotely
16:01:09 From Bryan St. Amour {CA - MayStreet} to Everyone:
	same.
16:01:52 From Patrice Roy to Everyone:
	Thanks everyone!
16:01:57 From John McFarlane to Everyone:
	Paper title please!
16:02:00 From Robin Rowe to Everyone:
	Thank you!
16:02:03 From Matthew Bentley {NZ, plflib.org} to Everyone:
	Sorry was late :)
16:02:12 From Brett to Everyone:
	See you soon