mention that PWSTR and PSTR are strings

[smasher164]

PWSTR and PSTR are uint16_t*. Is it possible to extend the metadata with info that they are string-like?

@tdakkota notes in golang/go#43838 (comment) that setting a TypeAttribute of AnsiClass/UnicodeClass or giving it ELEMENT_TYPE_STRING are possibilities.

Currently, windows-rs and zigwin32gen maintain a list of well-known types to deal with these.

[weltkante]

Currently, windows-rs and zigwin32gen maintain a list of well-known types to deal with these.

That probably can't be avoided. Nothing against annotating PWSTR and PSTR but there are other string-like types (probably mostly in the APIs involving COM) which require usage of specific allocators and string manipulation functions (i.e. not just a zero terminated sequence of characters), so projections always have to special case these.

If there's an annotation to be interoduced you need to chose the semantic of being a "string-like type" very carefully for it to have any value, otherwise it provides no gain if you still have to differentiate between the different string-like types in the projection anyways.

[smasher164]

you need to chose the semantic of being a "string-like type"

Right. This doesn't need to be a single piece of metadata. I think it would be useful to know information about the expected string, like whether it's null-terminated, its encoding, etc...

[marler8997]

Since I think these are the only 2 types the metadata uses to represent strings (i.e. pointers to null-terminated character arrays), I don't see a benefit to creating new attribute for this. Unless there are more types that would use these new attributes? Otherwise, checking for the specially named types PSTR and PWSTR wouldn't be much different than checking for a new "string-like" attribute.

[mikebattista]

@sotteson1 @kennykerr what are your thoughts on this? If WinRT is using ELEMENT_TYPE_STRING, should we be using it here?

[kennykerr]

That is already used by WinRT to represent HSTRING so that would be incompatible with language projections that support both WinRT and Win32. What we have now is a reasonable compromise to support both.

[mikebattista]

That probably can't be avoided. Nothing against annotating PWSTR and PSTR but there are other string-like types (probably mostly in the APIs involving COM) which require usage of specific allocators and string manipulation functions (i.e. not just a zero terminated sequence of characters), so projections always have to special case these.

BSTR is one such example, right?

That is already used by WinRT to represent HSTRING so that would be incompatible with language projections that support both WinRT and Win32. What we have now is a reasonable compromise to support both.

Ok. Is this a Won't Fix? Or is there anything we can/should do here?

[kennykerr]

We already have types for PSTR, PWSTR, BSTR, and so on. I don't there's anything to do here. Language projections must deal with these "well-known" types.