[Bug libstdc++/50641] New: [c++0x] is_convertible and is_constructible incorrectly require copy constructibility

[Bug libstdc++/50641] New: [c++0x] is_convertible and is_constructible incorrectly require copy constructibility

[luto at mit dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641

             Bug #: 50641
           Summary: [c++0x] is_convertible and is_constructible
                    incorrectly require copy constructibility
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: luto@mit.edu


is_convertible and is_constructible seem to either spew errors or return false
when the To type is not CopyConstructible.  (errors happen if the copy
constructor is private; false happens if it's deleted.)

Here's a test case:

#include <type_traits>

struct From
{
};

struct To
{
  To(const From &&);
  To(const To &) = delete;
};

template <class T>
typename std::add_rvalue_reference<T>::type create();

void test()
{
  /* From N3242 [meta.unary.prop], with the ... removed, in reference to
is_constructible. */
  To t(create<From>());
}

static_assert(std::is_constructible<From, To>::value, "not constructible");

static_assert(std::is_convertible<From, To>::value, "not convertible");

>From my reading of N3242, is_constructible should certainly return true, and
I'm having a hard time understanding the definition of is_convertible.

This causes the fancy new map::insert function to be less useful if the
mapped_type is not CopyConstructible.  That usage seems to be the whole point,
according to [map.modifiers], which says:

If P is instantiated as a reference type, then the argument x is copied from.
Otherwise x is con-sidered to be an rvalue as it is converted to value_type and
inserted into the map. Specifically, in such cases CopyConstructible is not
required of key_type or mapped_type unless the conversion from P specifically
requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type
must be CopyConstructible). The signature taking InputIterator parameters does
not require CopyConstructible of either key_type or mapped_type if the
dereferenced InputIterator returns a non-const rvalue
pair<key_type,mapped_type>. Otherwise CopyConstructible is required for both
key_type and mapped_type.

[Bug libstdc++/50641] [c++0x] is_convertible and is_constructible incorrectly require copy constructibility

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-06 23:44:32 UTC ---
Daniel, can you help triaging this?

[Bug libstdc++/50641] [c++0x] is_convertible and is_constructible incorrectly require copy constructibility

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641

--- Comment #2 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-10-07 05:36:02 UTC ---
1) The outcome of is_constructible is expected, because you cannot construct
From from To, the actually wanted test would have been 

static_assert(std::is_constructible<To, From>::value, "not constructible");

and this is correctly accepted.

2) The outcome of is_convertible is expected, because this traits is just a
trait to test for copy-initialization. Just add the line

To t2 = create<From>();

to your test function and this will fail too:

"error: use of deleted function 'To::To(const To&)"

This is expected because the current language requires that a temporary of the
target type To will be created which is than moved/copied into the final To
object. Alas, this must fail, because To does not have any copy constructor not
move constructor.

This looks like not-a-bug to me.

[Bug libstdc++/50641] [c++0x] is_convertible and is_constructible incorrectly require copy constructibility

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-10-07 06:46:56 UTC ---
(In reply to comment #2)
> This looks like not-a-bug to me.

This refers to the traits implementation. I believe that the core language
should consider to remove the need for the temporary that is required in
heterogeneous copy-initialization, but this is out of scope of gcc.

[Bug libstdc++/50641] [c++0x] is_convertible and is_constructible incorrectly require copy constructibility

[luto at mit dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641

--- Comment #4 from Andy Lutomirski <luto at mit dot edu> 2011-10-07 06:57:01 UTC ---
The problem I encountered that inspired this was:

#include <type_traits>
#include <map>

struct From
{
};

struct To
{
  To(const From &&) {}
  To(const To &) = delete;
  void operator = (const To &) = delete;
};

int main()
{
  std::map<int, To> m;
  m.insert(std::pair<int, From>(1, From()));
}

This works in 4.6.0 due to a different bug.  IMO it deserves to work -- the
implementation of map could move-construct the To object in place.  The
standard says explicitly that it's OK for To not to be CopyConstructible and,
indeed, this example works if I add:

To(const To &&) {}

I defer to the experts (and the people who have a copy of the FDIS) to figure
out whether it's supposed to work.  N3242 says that From needs to be
"convertible" to To, but I'm not at all convinced that "convertible" means the
same thing as "is_convertible".  Maybe if it's illegal I'll file a DR some day.

(N3242's section on map modifiers is woefully incomplete -- quite a few
functions are simply not there.  I hope the FDIS is better.)

[Bug libstdc++/50641] [c++0x] is_convertible and is_constructible incorrectly require copy constructibility

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641

--- Comment #5 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-10-07 07:13:50 UTC ---
(In reply to comment #4)
> N3242 says that From needs to be
> "convertible" to To, but I'm not at all convinced that "convertible" means the
> same thing as "is_convertible".  Maybe if it's illegal I'll file a DR some day.

It really means the same, "implicit conversion" is currently identical to
"copy-initialization".

Note that the example here is addressed by LWG issue 2005 and it should work,
once the specification changes it "is convertible" requirement to a
corresponding "is constructible" requirement. The current P/R of LWG 2005 does
not contain the revised wording suggestion, though.

[Bug libstdc++/50641] [c++0x] is_convertible and is_constructible incorrectly require copy constructibility

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-07 09:52:36 UTC ---
Thanks a lot Daniel. Thus, looks like it all boils down to "just" LWG 2005,
which we know well enough, I guess ;) and isn't a GCC issue.