[Bug c++/57684] [c++11] Lambda is not convertible to std::function

[Bug c++/57684] [c++11] Lambda is not convertible to std::function

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think the problem is that unordered_map requires its template arguments to be
complete at the time of instantiation, otherwise it's undefined behaviour.

When the static member is instantiated the type Derived is not complete,
because base<derived> is instantiated before the body of derived.

So although it would be nice if this worked, I think it technically relies on
undefined behaviour.

[Bug c++/57684] [c++11] Lambda is not convertible to std::function

[bluescarni at gmail dot com]

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

--- Comment #2 from Francesco Biscani <bluescarni at gmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> I think the problem is that unordered_map requires its template arguments to
> be complete at the time of instantiation, otherwise it's undefined behaviour.
> 
> When the static member is instantiated the type Derived is not complete,
> because base<derived> is instantiated before the body of derived.
> 
> So although it would be nice if this worked, I think it technically relies
> on undefined behaviour.

Thanks for the quick reply!

I understand this might be a bit OT here, but would wrapping the static member
in an std::unique_ptr avoid UB?

[Bug c++/57684] [c++11] Lambda is not convertible to std::function

[bluescarni at gmail dot com]

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

--- Comment #4 from Francesco Biscani <bluescarni at gmail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> Yes, because std::unique_ptr has a special exception that says it can be
> instantiated with incomplete types, so that should work OK (like your case
> where the static member is a raw pointer, which prevents unordered_map being
> instantiated when base<> is instantiated.
> 
> I hope for GCC 4.9 we can make unordered_map support incomplete types again,
> so the original code would work, but it doesn't support them currently,
> which is allowed by the standard.

Thanks for the explanation, gonna wrap my code in unique_ptr then.

As a side note, this seems to work for std::map, are the requirements different
regarding the completeness of types?

[Bug c++/57684] [c++11] Lambda is not convertible to std::function

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The standard says it is undefined to instantiate any std template with
incomplete types (with exceptions for shared_ptr and unique_ptr and maybe a few
others).  As an extension libstdc++ allows all containers to be instantiated
with incomplete types, except the unordered_xxx ones.

[Bug libstdc++/57684] [c++11] Lambda is not convertible to std::function

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #3)
> I hope for GCC 4.9 we can make unordered_map support incomplete types again,
> so the original code would work, but it doesn't support them currently,
> which is allowed by the standard.

This is not going to happen for 4.9, if ever.

[Bug libstdc++/57684] [c++11] Lambda is not convertible to std::function

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Known to work|                            |4.8.3, 4.9.1, 5.0
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.8.3
      Known to fail|                            |4.8.2, 4.9.0

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This was fixed by improving the constraints on the std::function constructor.