QByteArrayView is special..

[arnetheduck]

Similar to QByteArray but without the copy, this view-only type probably should be mapped to miqt_string - this also begs the question what to do with overloads that both decay to miqt_string, ie they likely can be removed such as in https://doc.qt.io/qt-6/qbytearraymatcher.html#QByteArrayMatcher-4

[arnetheduck]

Ditto QAnyStringView

[mappu]

Probably a duplicate of #142. 😄

Projecting as a miqt_string is reasonable. For Go there is a caveat that C(++) cannot hold pointers to Go memory beyond the lifetime of a C call in case Go GC's the memory, so depending exactly on the Qt API in question, there may need to be a memory copy anyway.

[arnetheduck]

there may need to be a memory copy anyway.

I think the intent of the type is that it's used only temporarily, ie passing in a regex that gets parsed to some internal structure - or in the case that it outlives the one function call, the caller can be responsible for ensuring things don't get collected (by holding a reference) - I came across it with QMetaType::fromName where it's used as a lookup key for example - here, a copy would be counterproductive.