Date: Fri, 24 Feb 2023 10:12:26 +0200
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.
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.
As I said, I have decided to literally save my time and effort not
bothering, but it is so glaring we are walking into another
concepts/contracts/modules/coroutines/executors design loops, that at least
I had to propose a limited scope in hope we can avoid another rabbit hole.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/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.
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.
As I said, I have decided to literally save my time and effort not
bothering, but it is so glaring we are walking into another
concepts/contracts/modules/coroutines/executors design loops, that at least
I had to propose a limited scope in hope we can avoid another rabbit hole.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-02-24 08:12:40