On Fri, Feb 24, 2023 at 3:12 AM Михаил Найденов via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
> On Thu, Feb 23, 2023 at 7:31 PM Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Thu, Feb 23, 2023 at 12:19 PM Михаил Найденов via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > One last revision. I have decided "not to bother", but after the last meeting PM is now "conservative C++29" target, which was added as a point in the motivation.
>> > This is I think the realistic-to-optimistic target, mainly because there are 2 completely different proposals in flight, both of which doing too much for an initial release (in my opinion obviously).
>> > We have to define some scope and get something finally.
>>
>
>>
>> You keep saying this, but you provide no evidence for it.
>
> The evidence is that from C++23, now we brace for C+29.

Your statement is that the scope of the feature is why it is being
delayed (and therefore a smaller scoped feature would be faster to
standardize). The fact that it was delayed is *not* evidence of *why*
it was delayed.

> Besides, though there was progress, it is "nullified" by having a new proposal.
>
>>
>> Why do you
>> think scope is the problem here?
>>
>> Why do you think your proposal would
>> be adopted faster?
>
>
> Limiting the scope is an easy way to reduce the amount of time needed.
>
> We will not have to argue should we have
> [member: 5] or [.member 5] or [.member: 5] for deconstructing w/ designators
> and then what the customization point would be, should we have any,
> if we don't have deconstructing w/ designators for the initial release.

Why do you think that such "arguments" are the problem, if they are
even happening at all?