Date: Fri, 14 Apr 2023 03:34:39 +0300
On 4/14/23 03:12, Edward Catmur via Std-Discussion wrote:
>
>
> On Thu, 13 Apr 2023, 21:08 Jason McKesson via Std-Discussion,
> <std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>> wrote:
>
> I really don't like the idea of picking functionality based on what is
> easiest to get through the committee instead of what is best for the
> language. If it's important enough to go into the standard, then it's
> important to do it in a reasonable way even if it's a bit harder. And
> if it's not important enough to be worth the effort, then maybe we
> shouldn't bother.
>
> The functionality would be exactly the same. The difference would be
> whether anyone other than the standard library would be able to
> implement it.
As a library implementor, I would be opposed to locking that
functionality to only the standard scope guards.
>
>
> On Thu, 13 Apr 2023, 21:08 Jason McKesson via Std-Discussion,
> <std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>> wrote:
>
> I really don't like the idea of picking functionality based on what is
> easiest to get through the committee instead of what is best for the
> language. If it's important enough to go into the standard, then it's
> important to do it in a reasonable way even if it's a bit harder. And
> if it's not important enough to be worth the effort, then maybe we
> shouldn't bother.
>
> The functionality would be exactly the same. The difference would be
> whether anyone other than the standard library would be able to
> implement it.
As a library implementor, I would be opposed to locking that
functionality to only the standard scope guards.
Received on 2023-04-14 00:34:43