Skip to content

Commit ac3906e

Browse files
committed
New issue from Dietmar Kühl: task uses unusual allocator customisation
1 parent bb05060 commit ac3906e

File tree

1 file changed

+37
-0
lines changed

1 file changed

+37
-0
lines changed

xml/issue4333.xml

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
<?xml version='1.0' encoding='utf-8' standalone='no'?>
2+
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
3+
4+
<issue num="4333" status="New">
5+
<title><code>task</code> uses unusual allocator customisation</title>
6+
<section><sref ref="[task.promise]"/></section>
7+
<submitter>Dietmar Kühl</submitter>
8+
<date>31 Aug 2025</date>
9+
<priority>99</priority>
10+
11+
<discussion>
12+
<p>
13+
Unlike <code>generator</code> the allocator customisation of
14+
<code>task</code> constraints the allocator type used for the
15+
coroutine to be convertible to the configured
16+
<code>allocator_type</code>. This prevents easy use of an allocator
17+
especially when no allocator is configured and the default
18+
(<code>std::allocator&lt;std::byte&gt;</code>) is used. The reason
19+
for this constraint is that the <code>get_allocator</code> is
20+
forwarded to <code>co_await</code>ed senders and is intended to be
21+
the same as the allocator used for the coroutine frame.
22+
</p>
23+
<p>
24+
It may be reasonable to allow use of an arbitrary allocator when
25+
there is no explicit configuration of the <code>allocator_type</code>.
26+
In this case it may also be resonable to not support the
27+
<code>get_allocator</code> query when <code>co_await</code>ing
28+
senders.
29+
</p>
30+
</discussion>
31+
32+
<resolution>
33+
<p>
34+
</p>
35+
</resolution>
36+
37+
</issue>

0 commit comments

Comments
 (0)