-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFE] allow assign to members of rvalue aggregate (-fpermissive
)
#40016
Comments
https://lkml.org/lkml/2018/9/13/1272 |
This example demonstrates permissive conversion from |
A general "support -fpermissive" bug is too vague to be actionable -- Can we repurpose this bug to specifically be about assigning to a subobject of a temporary? (Incidentally, we should likely also add direct support for a |
Not sure what is the best way of repurpose.
Would be good. |
By the way, The standard seems to say that a temporary materialization |
Temporary materialization conversion converts the |
Hi, what would be a resolution of this? |
This request does not seem particularly strongly motivated at least as explained currently. This case can covered using designated initializers e.g. #include <iostream>
#include <cstdlib>
class s {
public:
int a;
~s() { std::cout << "a=" << a << std::endl; }
};
static s foo()
{
return s{0};
}
int main()
{
(void)s{.a=10};
int *p = (int*)std::malloc(sizeof(int));
return *p;
} If we do a have a more strongly motivated case, I believe a RFC on Discourse would be more appropriate today. |
If it would be a new code then maybe
which means the destructor is never called
in which case after Basically speaking, there are many syntaxes |
We've traditionally been strongly opposed to |
I don't think my code represent a popular Anyway, I don't propose to judge my code.
Please provide me with an URL of such a |
"Completely useless" is a bit heavier of a term than I'd use, but it's still pretty unmotivated (at least, to me). One of the criteria for adding extensions to Clang (https://clang.llvm.org/get_involved.html#criteria) is that there be evidence of a significant user community. I think that's the primary thing that I'm missing which would motivate me.
Oddly, this came up literally this morning: #54120 -- but there are other mentions of this on the mailing lists and bug database. Also: https://reviews.llvm.org/D58154 |
Thanks. This particular extension wasn't discussed |
Correct, I've not seen a discussion of this particular aspect aside from on this thread.
See: #40016 (comment); the value category is important in terms of correctness, move semantics, and optimization opportunities.
I don't think it's a good extension to add. There are very, very few circumstances under which allowing assignment into an xvalue is reasonable, so adding this extension increases the chances of running into more bugs in order to work around what amounts to a design issue. You've found one of the cases where you could make an argument that the assignment is reasonable, but I think this is a quite rare situation, so it's not that compelling. Essentially, I don't think this meets the bar for an extension we'd be interested in adding to Clang, at least without further evidence that there is a greater need. (To be clear, this is not "no, we'll never do it" to this particular request -- this is "no, we need more evidence that there's sufficient community need for a new language dialect".) |
Its not a design issue. Its that gcc is
This is almost a chicken-and-egg problem: |
I think the correction is needed here: |
-fpermissive
)
@llvm/issue-subscribers-clang-frontend Author: None (llvmbot)
| | |
| --- | --- |
| Bugzilla Link | [40670](https://llvm.org/bz40670) |
| Version | unspecified |
| OS | Linux |
| Reporter | LLVM Bugzilla Contributor |
| CC | @DougGregor,@zygoloid |
Extended Description#include <iostream>
#include <cstdlib>
class s {
public:
int a;
~s() { std::cout << "a=" << a << std::endl; }
};
static s foo()
{
return s{0};
}
int main()
{
foo().a = 5;
int *p = std::malloc(sizeof(int));
return *p;
} This code can be compiled with g++ if |
However, GCC doesn't seem to restrict this to members of aggregate temporary objects. To me, the request is basically same as allowing the following (Godbolt link): int main()
{
int n;
static_cast<int&&>(n) = 42;
} I.e. making scalar xvalue (but not prvalue which shouldn't be materialized aggressively) assignable. I agree with @AaronBallman on that this extension is not good. |
But why no one have spoken exactly Let me remind that the benefit comes |
Extended Description
This code can be compiled with g++ if
-fpermissive
is used.clang++ doesn't compile it with any options.
The text was updated successfully, but these errors were encountered: