Embind 3.1.60 broke my binding.

[キャロウ マーク]

Hi,

I have a binding for a c pseudo object-oriented API. The binding has a very simple c++ class with a single unique_ptr that points at the underlying c object.

namespace ktx {

    class texture

    {

    private:

        texture(ktxTexture* ptr)

            : m_ptr{ ptr, &destroy }

        {

        }

        static void destroy(ktxTexture* ptr)

        {

            ktxTexture_Destroy(ptr);

        }

        std::unique_ptr<ktxTexture, decltype(&destroy)> m_ptr;

    public:

        texture(texture&) = delete;

        texture(texture&&) = default;

        static texture createFromMemory(const emscripten::val& data) {

            … 

        }

    }

}

The binding has

EMSCRIPTEN_BINDINGS(ktx)

{

 class_<ktx::texture>("ktxTexture")

        .constructor(&ktx::texture::createFromMemory)

        ;

}

This compiled and worked find up to and including Emscripten 3.1.59. But with 3.1.60 I get this error

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:365:20: error: call to deleted constructor of 'ActualT' (aka 'ktx::texture')

  365 |         return new ActualT(v);

      |                    ^       ~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:438:51: note: in instantiation of function template specialization 'emscripten::internal::GenericBindingType<ktx::texture>::toWireType<ktx::texture>' requested here

  438 |         return internal::BindingType<ReturnType>::toWireType(

      |                                                   ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1412:68: note: in instantiation of member function 'emscripten::internal::Invoker<emscripten::internal::rvp::default_tag, ktx::texture, const emscripten::val &>::invoke' requested here

 1412 |         auto invoke = &Invoker<ReturnPolicy, ReturnType, Args...>::invoke;

      |                                                                    ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1685:27: note: in instantiation of function template specialization 'emscripten::internal::RegisterClassConstructor<ktx::texture (*)(const emscripten::val &)>::invoke<ktx::texture>' requested here

 1685 |         invoker::template invoke<ClassType, Policies...>(callable);

      |                           ^

/src/interface/js_binding/ktx_wrapper.cpp:492:10: note: in instantiation of function template specialization 'emscripten::class_<ktx::texture>::constructor<emscripten::internal::DeduceArgumentsTag, ktx::texture (*)(const emscripten::val &)>' requested here

  492 |         .constructor(&ktx::texture::createFromMemory)

      |          ^

/src/interface/js_binding/ktx_wrapper.cpp:22:9: note: 'texture' has been explicitly marked deleted here

   22 |         texture(texture&) = delete;

      |         ^

1 error generated.

The copy constructor is deliberately marked “delete” because to implement I’d either have to make a copy of the c object or reference count it. Neither is appealing for the use I have.

Is this a bug in Emscripten or a deliberate change? If the latter how can I make it compile without having a copy constructor?

Regards

    -Mark

[Brendan Dahl]

This was a part of a change to add more explicit object ownership for bindings.  In this case you'd likely want to use a return_value_policy::take_ownership. There's more information in the docs if you're interested.

[キャロウ マーク]

On May 22, 2024, at 3:09, 'Brendan Dahl' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

This was a part of a change to add more explicit object ownership for bindings.  In this case you'd likely want to use a return_value_policy::take_ownership. There's more information in the docs if you're interested.

Thank you for your reply. I actually read those docs a few days ago and attempted to use return_value_policy. It is unknown in 3.1.59. Then I realized that the day I was reading the docs was 3 days after the PR with the functionality was merged so it was not yet released.

The bad news is that I get the same error after changing

.constructor(&ktx::texture::createFromMemory)

to

.constructor(&ktx::texture::createFromMemory, emscripten::return_value_policy::take_ownership()).

The good news is that a new version of the wrapper that I have been working on for a couple of weeks compiles successfully with 3.1.60.  The changes all add functionality. There are only cosmetic changes to the original code and no change to the constructor that is originating the compile error. I made the same cosmetic changes to the original and still get the compile error.  I am mystified as to why the new version compiles and the original doesn’t.

Any further hints welcome.

Regards

    -Mark

[キャロウ マーク]

On May 22, 2024, at 14:15, キャロウ　マーク <git...@callow.im> wrote:

The good news is that a new version of the wrapper that I have been working on for a couple of weeks compiles successfully with 3.1.60. 

Not good after all. It turns out the first build I did with 3.1.60, that prompted me to write the above, only relinked the wrapper. When it actually attempts to compile I get the original error and more.

Regards

    -Mark

[キャロウ マーク]

When on the verge of releasing a major chunk of work, having a new version of the compiler throw up 4 errors is extremely, extremely disappointing. The disappointment is compounded by being unable to find any documentation describing the effect of the compiler changes and how to adapt one’s code.  I have not found the documentation remotely helpful in understanding what is wrong. Must do better!

See the error log below. The subject “constructors” and the function are all returning a c++ class whose sole instance variable is  a std::unique_ptr, `return texture(ptr)` where `ptr` is the pointer to the c object in the Emscripten heap. Presumably this is “return by value.” Adding `return_value_policy::take_ownership())` made zero difference to the errors. Their binding declarations are

    class_<ktx::texture>("ktxTexture")

        .constructor(&ktx::texture::createFromMemory,

                     return_value_policy::take_ownership())

        .function("createCopy", &ktx::texture::createCopy,

                  return_value_policy::take_ownership())

        .constructor(&ktx::texture::create,

                     return_value_policy::take_ownership())

        .constructor(&ktx::texture::createFromBuffer,

                     return_value_policy::take_ownership())

    ;

The method declarations are:

static texture createFromMemory(const emscripten::val& data) { }

texture createCopy() { }

static texture create(const ktxTextureCreateInfo& createInfo, ktxTextureCreateStorageEnum storageAllocation) { }

static texture createFromBuffer(const emscripten::val& data, int width, int height, int comps, bool srgb) { }

Only the error for the first “constructor” mentions “call to deleted constructor”. The other errors complain about “no matching function for call to ‘toWireType”.

Here is the full error record:

[ 75%] Building CXX object CMakeFiles/ktx_js.dir/interface/js_binding/ktx_wrapper.cpp.o

In file included from /src/interface/js_binding/ktx_wrapper.cpp:9:

In file included from /emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:26:

In file included from /emsdk/upstream/emscripten/cache/sysroot/include/emscripten/val.h:17:

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:365:20: error: call to deleted constructor of 'ActualT' (aka 'ktx::texture')

  365 |         return new ActualT(v);

      |                    ^       ~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:438:51: note: in instantiation of function template specialization 'emscripten::internal::GenericBindingType<ktx::texture>::toWireType<ktx::texture>' requested here

  438 |         return internal::BindingType<ReturnType>::toWireType(

      |                                                   ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1412:68: note: in instantiation of member function 'emscripten::internal::Invoker<emscripten::internal::rvp::default_tag, ktx::texture, const emscripten::val &>::invoke' requested here

 1412 |         auto invoke = &Invoker<ReturnPolicy, ReturnType, Args...>::invoke;

      |                                                                    ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1685:27: note: in instantiation of function template specialization 'emscripten::internal::RegisterClassConstructor<ktx::texture (*)(const emscripten::val &)>::invoke<ktx::texture, emscripten::return_value_policy::take_ownership>' requested here

 1685 |         invoker::template invoke<ClassType, Policies...>(callable);

      |                           ^

/src/interface/js_binding/ktx_wrapper.cpp:1019:10: note: in instantiation of function template specialization 'emscripten::class_<ktx::texture>::constructor<emscripten::internal::DeduceArgumentsTag, ktx::texture (*)(const emscripten::val &), emscripten::return_value_policy::take_ownership>' requested here

 1019 |         .constructor(&ktx::texture::createFromMemory,

      |          ^

/src/interface/js_binding/ktx_wrapper.cpp:78:9: note: 'texture' has been explicitly marked deleted here

   78 |         texture(texture&) = delete;

      |         ^

In file included from /src/interface/js_binding/ktx_wrapper.cpp:9:

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:682:16: error: no matching function for call to 'toWireType'

  682 |         return internal::BindingType<ReturnType>::toWireType(

      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:472:50: note: in instantiation of member function 'emscripten::internal::MethodInvoker<emscripten::internal::rvp::default_tag, ktx::texture (ktx::texture::*)(), ktx::texture, ktx::texture *>::invoke' requested here

  472 |         async::Wrapper<decltype(&T::invoke), &T::invoke>,

      |                                                  ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1765:27: note: in instantiation of function template specialization 'emscripten::internal::RegisterClassMethod<ktx::texture (ktx::texture::*)()>::invoke<ktx::texture>' requested here

 1765 |         invoker::template invoke<ClassType, Policies...>(methodName, callable);

      |                           ^

/src/interface/js_binding/ktx_wrapper.cpp:1021:10: note: in instantiation of function template specialization 'emscripten::class_<ktx::texture>::function<emscripten::internal::DeduceArgumentsTag, ktx::texture (ktx::texture::*)()>' requested here

 1021 |         .function("createCopy", &ktx::texture::createCopy)

      |          ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:369:21: note: candidate function template not viable: no known conversion from 'emscripten::internal::rvp::default_tag' to 'rvp::take_ownership' for 2nd argument

  369 |     static WireType toWireType(R&& v, rvp::take_ownership) {

      |                     ^                 ~~~~~~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:374:21: note: candidate function template not viable: no known conversion from 'emscripten::internal::rvp::default_tag' to 'rvp::reference' for 2nd argument

  374 |     static WireType toWireType(R&& v, rvp::reference) {

      |                     ^                 ~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:364:21: note: candidate template ignored: substitution failure [with R = ktx::texture]

  364 |     static WireType toWireType(R&& v, rvp::default_tag) {

      |                     ^

In file included from /src/interface/js_binding/ktx_wrapper.cpp:9:

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:438:16: error: no matching function for call to 'toWireType'

  438 |         return internal::BindingType<ReturnType>::toWireType(

      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1412:68: note: in instantiation of member function 'emscripten::internal::Invoker<emscripten::internal::rvp::default_tag, ktx::texture, const ktxTextureCreateInfo &, ktxTextureCreateStorageEnum>::invoke' requested here

 1412 |         auto invoke = &Invoker<ReturnPolicy, ReturnType, Args...>::invoke;

      |                                                                    ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1685:27: note: in instantiation of function template specialization 'emscripten::internal::RegisterClassConstructor<ktx::texture (*)(const ktxTextureCreateInfo &, ktxTextureCreateStorageEnum)>::invoke<ktx::texture, emscripten::return_value_policy::take_ownership>' requested here

 1685 |         invoker::template invoke<ClassType, Policies...>(callable);

      |                           ^

/src/interface/js_binding/ktx_wrapper.cpp:1049:10: note: in instantiation of function template specialization 'emscripten::class_<ktx::texture>::constructor<emscripten::internal::DeduceArgumentsTag, ktx::texture (*)(const ktxTextureCreateInfo &, ktxTextureCreateStorageEnum), emscripten::return_value_policy::take_ownership>' requested here

 1049 |         .constructor(&ktx::texture::create,

      |          ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:369:21: note: candidate function template not viable: no known conversion from 'emscripten::internal::rvp::default_tag' to 'rvp::take_ownership' for 2nd argument

  369 |     static WireType toWireType(R&& v, rvp::take_ownership) {

      |                     ^                 ~~~~~~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:374:21: note: candidate function template not viable: no known conversion from 'emscripten::internal::rvp::default_tag' to 'rvp::reference' for 2nd argument

  374 |     static WireType toWireType(R&& v, rvp::reference) {

      |                     ^                 ~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:364:21: note: candidate template ignored: substitution failure [with R = ktx::texture]

  364 |     static WireType toWireType(R&& v, rvp::default_tag) {

      |                     ^

In file included from /src/interface/js_binding/ktx_wrapper.cpp:9:

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:438:16: error: no matching function for call to 'toWireType'

  438 |         return internal::BindingType<ReturnType>::toWireType(

      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1412:68: note: in instantiation of member function 'emscripten::internal::Invoker<emscripten::internal::rvp::default_tag, ktx::texture, const emscripten::val &, int, int, int, bool>::invoke' requested here

 1412 |         auto invoke = &Invoker<ReturnPolicy, ReturnType, Args...>::invoke;

      |                                                                    ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:1685:27: note: in instantiation of function template specialization 'emscripten::internal::RegisterClassConstructor<ktx::texture (*)(const emscripten::val &, int, int, int, bool)>::invoke<ktx::texture>' requested here

 1685 |         invoker::template invoke<ClassType, Policies...>(callable);

      |                           ^

/src/interface/js_binding/ktx_wrapper.cpp:1051:10: note: in instantiation of function template specialization 'emscripten::class_<ktx::texture>::constructor<emscripten::internal::DeduceArgumentsTag, ktx::texture (*)(const emscripten::val &, int, int, int, bool)>' requested here

 1051 |         .constructor(&ktx::texture::createFromBuffer)

      |          ^

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:369:21: note: candidate function template not viable: no known conversion from 'emscripten::internal::rvp::default_tag' to 'rvp::take_ownership' for 2nd argument

  369 |     static WireType toWireType(R&& v, rvp::take_ownership) {

      |                     ^                 ~~~~~~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:374:21: note: candidate function template not viable: no known conversion from 'emscripten::internal::rvp::default_tag' to 'rvp::reference' for 2nd argument

  374 |     static WireType toWireType(R&& v, rvp::reference) {

      |                     ^                 ~~~~~~~~~~~~~~

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:364:21: note: candidate template ignored: substitution failure [with R = ktx::texture]

  364 |     static WireType toWireType(R&& v, rvp::default_tag) {

      |                     ^

4 errors generated.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/F2B102E4-89FB-422F-85C8-1CA44214C7CA%40callow.im.

[キャロウ マーク]

On May 22, 2024, at 15:30, キャロウ　マーク <git...@callow.im> wrote:

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:365:20: error: call to deleted constructor of 'ActualT' (aka 'ktx::texture')

  365 |         return new ActualT(v);

It appears the `return_value_policy` setting is being ignored. The above line with the error is code that handles the default policy.

    template<typename R>

    static WireType toWireType(R&& v, rvp::default_tag) {

        return new ActualT(v);    <==== Line 365 or wire.h.

    }

Is some -s setting required to make Emscripten pay attention to return policies? I couldn’t find one but I may have been searching for the wrong string.

Regards

    -Mark

[キャロウ マーク]

On May 22, 2024, at 16:43, キャロウ　マーク <git...@callow.im> wrote:

It appears the `return_value_policy` setting is being ignored. The above line with the error is code that handles the default policy.

    template<typename R>

    static WireType toWireType(R&& v, rvp::default_tag) {

        return new ActualT(v);    <==== Line 365 or wire.h.

    }

Is some -s setting required to make Emscripten pay attention to return policies? I couldn’t find one but I may have been searching for the wrong string.

I missed it in the blizzard of messages but return_value_policy::take_ownership is actually working for the .function in the binding list I gave earlier but not for the .constructor items. How can I apply return_value_policy to a .constructor?

Regards

    -Mark

[Sam Clegg]

On Tue, May 21, 2024 at 11:30 PM キャロウ　マーク <git...@callow.im> wrote:

When on the verge of releasing a major chunk of work, having a new version of the compiler throw up 4 errors is extremely, extremely disappointing. The disappointment is compounded by being unable to find any documentation describing the effect of the compiler changes and how to adapt one’s code.  I have not found the documentation remotely helpful in understanding what is wrong. Must do better!

Please try to be respectful and understanding here in this forum. 

If there are issues with the 3.1.60 we will do our best to resolve them.  In the meantime, your project should be able to continue to use 3.1.59.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/DEBA24D8-73BC-4F8A-9B63-A1FF32188B70%40callow.im.

[キャロウ マーク]

On May 22, 2024, at 23:47, 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

On Tue, May 21, 2024 at 11:30 PM キャロウ　マーク <git...@callow.im> wrote:

When on the verge of releasing a major chunk of work, having a new version of the compiler throw up 4 errors is extremely, extremely disappointing. The disappointment is compounded by being unable to find any documentation describing the effect of the compiler changes and how to adapt one’s code.  I have not found the documentation remotely helpful in understanding what is wrong. Must do better!

Please try to be respectful and understanding here in this forum. 

What part of the paragraph do you feel was disrespectful?

If there are issues with the 3.1.60 we will do our best to resolve them.  In the meantime, your project should be able to continue to use 3.1.59.

Changing CI to stick with 3.1.59 is a similar amount of work to fixing the issue except that for changing CI there are probably fewer unknown unknowns.

I have fixed my binding by changing it to use real constructors, which return nothing, as constructors instead of functions with return values. That is instead of

    class_<ktx::texture>("ktxTexture")

        .constructor(&ktx::texture::createFromMemory,

                     return_value_policy::take_ownership())

        .constructor(&ktx::texture::create,

                     return_value_policy::take_ownership())

        .constructor(&ktx::texture::createFromBuffer,

                     return_value_policy::take_ownership())

    ;

I have 

        .constructor<const val>()

        .constructor<const ktxTextureCreateInfo&, ktxTextureCreateStorageEnum>()

        .constructor<const val&, int, int, int, bool>()

matching constructors in the C++ code.

I created the binding too many years ago to recall why I used functions for constructors. They look weird now. However embind still supports doing so. It looks like an oversight to me that 3.1.60 does not support use of return_value_policy in such constructors and a bug that is silently ignores such when present.

Regards

    -Mark

[Brendan Dahl]

This will be fixed by https://github.com/emscripten-core/emscripten/pull/21981. We didn't have any test cases using an external constructor that returns by value.

[Sam Clegg]

On Wed, May 22, 2024 at 10:03 PM キャロウ　マーク <git...@callow.im> wrote:

On May 22, 2024, at 23:47, 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

On Tue, May 21, 2024 at 11:30 PM キャロウ　マーク <git...@callow.im> wrote:

When on the verge of releasing a major chunk of work, having a new version of the compiler throw up 4 errors is extremely, extremely disappointing. The disappointment is compounded by being unable to find any documentation describing the effect of the compiler changes and how to adapt one’s code.  I have not found the documentation remotely helpful in understanding what is wrong. Must do better!

Please try to be respectful and understanding here in this forum. 

What part of the paragraph do you feel was disrespectful?

I found the tone of your comment to be very harsh.  The folks who work on emscripten are doing their best to build something that works for our users and gets better over time.   Calling things "extremely, extremely disappointing" and demanding "Must do better!" could come across to some as entitled.   Just toning it down a little would likely be better received and yield better outcomes, which we all want of course.

If there are issues with the 3.1.60 we will do our best to resolve them.  In the meantime, your project should be able to continue to use 3.1.59.

Changing CI to stick with 3.1.59 is a similar amount of work to fixing the issue except that for changing CI there are probably fewer unknown unknowns.

I have fixed my binding by changing it to use real constructors, which return nothing, as constructors instead of functions with return values. That is instead of

    class_<ktx::texture>("ktxTexture")

        .constructor(&ktx::texture::createFromMemory,

                     return_value_policy::take_ownership())

        .constructor(&ktx::texture::create,

                     return_value_policy::take_ownership())

        .constructor(&ktx::texture::createFromBuffer,

                     return_value_policy::take_ownership())

    ;

I have 

        .constructor<const val>()

        .constructor<const ktxTextureCreateInfo&, ktxTextureCreateStorageEnum>()

        .constructor<const val&, int, int, int, bool>()

matching constructors in the C++ code.

I created the binding too many years ago to recall why I used functions for constructors. They look weird now. However embind still supports doing so. It looks like an oversight to me that 3.1.60 does not support use of return_value_policy in such constructors and a bug that is silently ignores such when present.

Regards

    -Mark

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/178F98B9-73FE-471F-80A9-DD1A4EF577EE%40callow.im.

[キャロウ マーク]

On May 24, 2024, at 3:08, 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

On Wed, May 22, 2024 at 10:03 PM キャロウ　マーク <git...@callow.im> wrote:

On May 22, 2024, at 23:47, 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

On Tue, May 21, 2024 at 11:30 PM キャロウ　マーク <git...@callow.im> wrote:

When on the verge of releasing a major chunk of work, having a new version of the compiler throw up 4 errors is extremely, extremely disappointing. The disappointment is compounded by being unable to find any documentation describing the effect of the compiler changes and how to adapt one’s code.  I have not found the documentation remotely helpful in understanding what is wrong. Must do better!

Please try to be respectful and understanding here in this forum. 

What part of the paragraph do you feel was disrespectful?

I found the tone of your comment to be very harsh.  The folks who work on emscripten are doing their best to build something that works for our users and gets better over time.   Calling things "extremely, extremely disappointing" and demanding "Must do better!" could come across to some as entitled.   Just toning it down a little would likely be better received and yield better outcomes, which we all want of course.

I agree the chiding at the end was harsh. I am sorry it upset you. The rest of it was expressing my feelings. Make of them what you will. My feeling of disappointment was compounded by discovering, on the same day, that another compiler update was causing that compiler to  not compile another part of my project.

I have fixed my binding by changing it to use real constructors, which return nothing, as constructors instead of functions with return values. That is instead of

    class_<ktx::texture>("ktxTexture")

        .constructor(&ktx::texture::createFromMemory,

                     return_value_policy::take_ownership())

        .constructor(&ktx::texture::create,

                     return_value_policy::take_ownership())

        .constructor(&ktx::texture::createFromBuffer,

                     return_value_policy::take_ownership())

    ;

I have 

        .constructor<const val>()

        .constructor<const ktxTextureCreateInfo&, ktxTextureCreateStorageEnum>()

        .constructor<const val&, int, int, int, bool>()

matching constructors in the C++ code.

I created the binding too many years ago to recall why I used functions for constructors. They look weird now. However embind still supports doing so. It looks like an oversight to me that 3.1.60 does not support use of return_value_policy in such constructors and a bug that is silently ignores such when present.

Should I open an issue about this? I am not sure function-as-constructor is still a reasonable thing to do, if it ever was. If it is them I’m pretty sure return_value_policy needs to be supported for that use.

Regards

    -Mark