Date: Sat, 25 Feb 2023 11:59:01 -0500
On Sat, Feb 25, 2023 at 2:55 AM Михаил Найденов via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Sat, Feb 25, 2023 at 12:38 AM Barry Revzin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>> > 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?
>>
>>
>> They are indeed not.
>
>
> We are speculating at this point, but the overall discussion has not reached that point to care about bikishadding.
> When the time comes, there is great possibility, will have such a discussion, I only wish to move it beyond 26.
>
> But it is not just bikeshedding, this exact topic will require expensive discussions about a customization point.
> If we do not provide one what is the value of having this? C++ values its encapsulation, do we really want to encourage using structs in order to use the fancy new PM?
>
>>
>>
>> Here's the thing, this paper isn't very useful. It's proposing six things as "high priority", but apparently nothing else is even medium or low priority?
>>
>>
>>
>> But also none of those "nothing else"s is even listed anywhere. It's not clear what it is that you're attempting to move out of scope.
>
>
> This is backwards, I believe. It must be proven something must be added, not the other way around.
>
> Say we have PM in the language, if someone wants a new feature, say extractors, they must prove the need and why this way is the best one to do it.
>
> There is no reason not to apply this logic here - have a core set now, whatever it might be, finish it, release it, then do the rest in iterations.
> I have never said, what will be removed must be buried and never looked at again.
Here's the problem. Consider C++0x concepts vs C++20 concepts.
C++0x concepts required definition checking; that was a core pillar of
the feature. C++20 concepts did not. This means that the C++20 concept
feature was able to look at concept strategies that would make
definition checking functionally *impossible*. And... that's what we
have now: a concept feature that is good and useful, but can *never*
have definition checking.
You could argue that definition checking was a pipe-dream, and you'd
probably be right. But my point is that if your design does not
consider future features, then it runs the real risk of moving in a
direction which makes adding those features in the future
*impossible*. If you shrink the scope of something, you stand a good
chance of putting those things out-of-scope *permanently*.
>> Nor does it even argue why whatever those "nothing else"s are what is the real problem with pattern matching - and that thus removing those from scope would make it easier to adopt pattern matching.
>
>
> There is no "real problem" w/ PM and even if there is, it is probably not in features proposed to postpone. This does not change the fact, postponing features will, by definition, give us more time for "the real problems" and improve delivery.
... will it, though?
Consider an analogy: traffic. Given a road with a certain number of
lanes, you can get some number of cars through that road. If you put
too many cars on the road, then traffic congestion happens and you get
fewer cars able to make it through in a given period of time. If
that's the case, limiting the number of cars that can get onto the
road can increase throughput.
So, you're seeing a situation where the throughput of cars is less
than optimal (in our analogy, that is the speed of PM
standardization). So you say we should limit the number of cars that
can get onto the road (the scope of PM).
But what if the problem is *not* too many cars causing traffic
congestion? What if instead there is an *accident on the road* that
needs to be cleaned up? You're putting fewer cars on the road, but
you're not getting them through any faster because the wreck is still
there; you haven't fixed the actual problem.
When you have people who have actual knowledge of what's happening on
the road saying, "fewer cars won't actually help, we need to do
something else," you should listen to them.
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Sat, Feb 25, 2023 at 12:38 AM Barry Revzin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>> > 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?
>>
>>
>> They are indeed not.
>
>
> We are speculating at this point, but the overall discussion has not reached that point to care about bikishadding.
> When the time comes, there is great possibility, will have such a discussion, I only wish to move it beyond 26.
>
> But it is not just bikeshedding, this exact topic will require expensive discussions about a customization point.
> If we do not provide one what is the value of having this? C++ values its encapsulation, do we really want to encourage using structs in order to use the fancy new PM?
>
>>
>>
>> Here's the thing, this paper isn't very useful. It's proposing six things as "high priority", but apparently nothing else is even medium or low priority?
>>
>>
>>
>> But also none of those "nothing else"s is even listed anywhere. It's not clear what it is that you're attempting to move out of scope.
>
>
> This is backwards, I believe. It must be proven something must be added, not the other way around.
>
> Say we have PM in the language, if someone wants a new feature, say extractors, they must prove the need and why this way is the best one to do it.
>
> There is no reason not to apply this logic here - have a core set now, whatever it might be, finish it, release it, then do the rest in iterations.
> I have never said, what will be removed must be buried and never looked at again.
Here's the problem. Consider C++0x concepts vs C++20 concepts.
C++0x concepts required definition checking; that was a core pillar of
the feature. C++20 concepts did not. This means that the C++20 concept
feature was able to look at concept strategies that would make
definition checking functionally *impossible*. And... that's what we
have now: a concept feature that is good and useful, but can *never*
have definition checking.
You could argue that definition checking was a pipe-dream, and you'd
probably be right. But my point is that if your design does not
consider future features, then it runs the real risk of moving in a
direction which makes adding those features in the future
*impossible*. If you shrink the scope of something, you stand a good
chance of putting those things out-of-scope *permanently*.
>> Nor does it even argue why whatever those "nothing else"s are what is the real problem with pattern matching - and that thus removing those from scope would make it easier to adopt pattern matching.
>
>
> There is no "real problem" w/ PM and even if there is, it is probably not in features proposed to postpone. This does not change the fact, postponing features will, by definition, give us more time for "the real problems" and improve delivery.
... will it, though?
Consider an analogy: traffic. Given a road with a certain number of
lanes, you can get some number of cars through that road. If you put
too many cars on the road, then traffic congestion happens and you get
fewer cars able to make it through in a given period of time. If
that's the case, limiting the number of cars that can get onto the
road can increase throughput.
So, you're seeing a situation where the throughput of cars is less
than optimal (in our analogy, that is the speed of PM
standardization). So you say we should limit the number of cars that
can get onto the road (the scope of PM).
But what if the problem is *not* too many cars causing traffic
congestion? What if instead there is an *accident on the road* that
needs to be cleaned up? You're putting fewer cars on the road, but
you're not getting them through any faster because the wreck is still
there; you haven't fixed the actual problem.
When you have people who have actual knowledge of what's happening on
the road saying, "fewer cars won't actually help, we need to do
something else," you should listen to them.
Received on 2023-02-25 16:59:53