Date: Thu, 23 May 2024 09:48:24 -0300
On Thursday 23 May 2024 05:49:11 GMT-3 Frederick Virchanza Gotham via Std-
Proposals wrote:
> you appear to have perceived Tiago to have
> been making a more generic point along the lines of "It's pointless
> for mutexes and it's pointless for every other class too".
No, I perceived as slightly but significantly different: "It's pointless for
mutexes and may be the same for every other class too". The point being that
we want to see a couple of other use-cases to judge whether it is valuable to
have the core language feature or not.
> A handful of extremely skilled programmers on this mailing list
> latched onto my mutex example because it's simple and shows the
> principle. And while I'm not a mind reader and haven't conducted a
> survey, I estimate that 9 out of 10 people here knew that std::mutex
> was being used for only one reason: It's unmovable and uncopyable. No
> other reason.
I think we all got that. I was there at the beginning when you were using
"widget" like Anton's paper did, so I know this for a fact. But two problems
remain:
* one, not everyone saw the beginning of the discussion and using a bad
example leads people down the wrong path
* we still need to see a few real cases where this would be useful.
> My main
> argument in favour of having NRVO is just simple a visceral feeling
> that "This is something that we should have in our toolbox", as I want
> C++ to be versatile and have all sort of features that can be used in
> all sorts of ways.
And I have the same but as Tiago pointed out in his reply, "visceral feeling"
does not belong in the papers. You'll have to provide a real motivation,
showing what code looks like today, what it would look like in the future, how
widespread this is, and what alternatives were considered.
Even though I have the same feeling, I don't actually think there are
significant enough use-cases to warrant a language change, not with the number
of pitfalls it will open due to exceptions and other mid-function returns.
This is also just a feeling.
Proposals wrote:
> you appear to have perceived Tiago to have
> been making a more generic point along the lines of "It's pointless
> for mutexes and it's pointless for every other class too".
No, I perceived as slightly but significantly different: "It's pointless for
mutexes and may be the same for every other class too". The point being that
we want to see a couple of other use-cases to judge whether it is valuable to
have the core language feature or not.
> A handful of extremely skilled programmers on this mailing list
> latched onto my mutex example because it's simple and shows the
> principle. And while I'm not a mind reader and haven't conducted a
> survey, I estimate that 9 out of 10 people here knew that std::mutex
> was being used for only one reason: It's unmovable and uncopyable. No
> other reason.
I think we all got that. I was there at the beginning when you were using
"widget" like Anton's paper did, so I know this for a fact. But two problems
remain:
* one, not everyone saw the beginning of the discussion and using a bad
example leads people down the wrong path
* we still need to see a few real cases where this would be useful.
> My main
> argument in favour of having NRVO is just simple a visceral feeling
> that "This is something that we should have in our toolbox", as I want
> C++ to be versatile and have all sort of features that can be used in
> all sorts of ways.
And I have the same but as Tiago pointed out in his reply, "visceral feeling"
does not belong in the papers. You'll have to provide a real motivation,
showing what code looks like today, what it would look like in the future, how
widespread this is, and what alternatives were considered.
Even though I have the same feeling, I don't actually think there are
significant enough use-cases to warrant a language change, not with the number
of pitfalls it will open due to exceptions and other mid-function returns.
This is also just a feeling.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Fleet Engineering and Quality
Received on 2024-05-23 12:48:28