#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 -fpermissive is used. clang++ doesn't compile it with any options.
https://lkml.org/lkml/2018/9/13/1272 LKML people also seem to want -fpermissive, and overall google shows quite a lot of demand.
This example demonstrates permissive conversion from void*, and also an extension to write fields of an aggregate returned as rvalue. This is a useful extension, because in the destructor you can have the use of the altered fields, as the example demonstrates. This is a main motivation why I think -fpermissive should be supported (permissive conversions are not so important). g++ supports both, and probably more extensions under -fpermissive (can't find the exact docs).
A general "support -fpermissive" bug is too vague to be actionable -- -fpermissive covers a lot of GNU extensions, some of which we already implement, some of which might be useful but are not currently supported in Clang, and others of which we might want to specifically take a stand against implementing. 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 -fpermissive flag, and make it downgrade all of our error-by-default extensions into warnings.)
(In reply to Richard Smith from comment #3) > Can we repurpose this bug to specifically be about assigning to a subobject > of a temporary? Not sure what is the best way of repurpose. I changed the description. But will it be activated with -fpermissive, or otherwise? > (Incidentally, we should likely also add direct support for a -fpermissive > flag, and make it downgrade all of our error-by-default extensions into > warnings.) Would be good. AFAIK this is all it does.
By the way, https://en.cppreference.com/w/cpp/language/implicit_conversion#Temporary_materialization The standard seems to say that a temporary materialization occurs "when performing a member access on a class prvalue;", which seems to be the case here. So I even wonder why it is not assignable by default? Is materialization not sufficient to became assignable?
Temporary materialization conversion converts the s prvalue to an s xvalue. Class member access then gives an int xvalue. Assignment needs an lvalue; an xvalue won't do.