XDN03 - xlang type system

[devhawk]

Note, this XDN is not complete. I'm putting it into PR to enable comments on the content that is available.

[bbowman]

Are we sure we want to support unsigned fundamental types (particularly 64 bit versions)? Some languages (like Java) don’t have a strong unsigned data story.

[devhawk]

@bbowman We debated about unsigned types back when we were designing WinRT, but I wasn't involved in the discussion. @BrentRe might have more context on that debate.

[bbowman]

Will there be a separate design note for the "Foundation" / standard library types? I see some mention of IVector, IPropertySet, etc. here but no mention of Asyncs, Uris, or other types that might reasonably be expected to be a foundational runtime class available to all authors?

[devhawk]

@bbowman yes, I need to add a stub XDN for the xlang foundation types. Async and Collections at a minimum. Personally, I also want to have Rx interfaces (IObverver/IObservable) included the foundation.

We need to talk about nullability and boxing before we settle on an approach to property values, which in turn will affect IPropertySet. But that will likely be in foundation as well

URI I'm not sure on yet. It's NOT a part of the WinRT foundation contract (though it is in the foundation namespace). On the one hand, most languages have some concept of URI so it would be nice customize the projection of xlang uri. On the other, we don't have any types in the foundation that use URI. I'm wondering if we (or someone) might eventually ship a network xlang component. If so, should URI live there? TO be debated.

2019-01-15 UPDATE: I created XDN07 for foundation types.

[zooba]

URIs have a canonical representation as a string, and everything else is just spans within the string/interpretations of substrings. Similarly for file system paths.

So I'd love to see a rich, transferable representation for both URIs and files/directories, as that moves more well-known validation into the ABI layer. But the underlying transfer type is really just a string, so I really just want a "project as string with extra validation if you know how" type, rather than being forced into matching the same properties between languages (for example, Python's urlsplit and WinHttpCrackUrl produce different results, plus Python doesn't have a URL "type", so passing through a string that can become a System.Url in .NET but be passed back as an .AbsoluteUrl string for other languages is fine).

[devhawk]

@zooba Agreed on URI and file system path representation. However, this isn't the doc for that. I've started XDN07 for foundational types. It's just stubs right now. There's already a stub for URI, but not file paths. Feel free to add a stub section for file paths to that doc or open an issue

[devhawk]

FYI, all the feedback in this PR has been addressed. I want to start on a new revision of this doc, so I'm going to go ahead and accept this PR. New PR w/ new changes coming soon