{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/corefx/issues/26948","repository_url":"https://api.github.com/repos/dotnet/corefx","labels_url":"https://api.github.com/repos/dotnet/corefx/issues/26948/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/corefx/issues/26948/comments","events_url":"https://api.github.com/repos/dotnet/corefx/issues/26948/events","html_url":"https://github.com/dotnet/corefx/issues/26948","id":295333701,"number":26948,"title":"Need a method similar to S.R.CS.RuntimeHelpers.InitializeArray, but for spans","user":{"login":"VSadov","id":8218165,"avatar_url":"https://avatars0.githubusercontent.com/u/8218165?v=4","gravatar_id":"","url":"https://api.github.com/users/VSadov","html_url":"https://github.com/VSadov","followers_url":"https://api.github.com/users/VSadov/followers","following_url":"https://api.github.com/users/VSadov/following{/other_user}","gists_url":"https://api.github.com/users/VSadov/gists{/gist_id}","starred_url":"https://api.github.com/users/VSadov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/VSadov/subscriptions","organizations_url":"https://api.github.com/users/VSadov/orgs","repos_url":"https://api.github.com/users/VSadov/repos","events_url":"https://api.github.com/users/VSadov/events{/privacy}","received_events_url":"https://api.github.com/users/VSadov/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2018-02-07T23:38:33Z","updated_at":"2018-02-08T05:13:51Z","closed_at":null,"author_association":"MEMBER","body":"Initialization of literal arrays like `new int[]{1,2,3,4,5,6}` has a special path where the blittable data is stored directly in the PE data and at runtime, instead of assigning every element of the array to a corresponding constant, we call `InitializeArray` with the target array instance and the token for the field that represents the data blob.\r\n\r\nSimilar technique would be very useful when initializing spans. \r\nWe already have two scenarios:\r\n* stack allocated spans -   `stackalloc int[] {1,2,3,4,5}`\r\n* optimized conversion  of literal arrays to ReadOnlySpan -  ` (ReadOnlySpan<int>)new int[]{1,2,3,4,5}`\r\n\r\nin fact in the case with ReadOnlySpan conversion, it would be possible and desirable to just refer to the PE data directly.\r\n\r\nThe preferred form of the API would be:\r\n\r\n```C#\r\n        ReadOnlySpan<T> GetGetReadOnlySpanFromTemplate<T>(RuntimeFieldHandle fldHandle);\r\n```\r\n\r\nAnother acceptable alternative is:  \r\n (but the one above feels more convenient since verifiability is less of a problem)\r\n\r\n```C#\r\n        ref T GetRefToTemplateData<T>(RuntimeFieldHandle fldHandle);\r\n```\r\n\r\nA valid question to be asked here - \"if it is possible to just load a reference to the field in the first place, why there is a need for the API?\"\r\n\r\nThe problem is that the blob data is always stored in littleendian format, so on a bigendian machine the blob data is valid only for 1-byte sized elements.  \r\nSimilarly to the case of `InitializeArray`, this API would allow the runtime to abstract away the endianness of the blob. \r\nIn a littleendian context (which is the most common case) the implementation could trivially forward to the field data and in bigendian case it may do fixups by either making a copy of the data while changing the endianness or even by performing the fixup in-place.\r\n\r\nNOTE: possibility of in-place fixup would require that the same blob is not used to initialize span data of different sizes - say shorts and longs. \r\nSuch restriction would be acceptable on the C# side and runtime could validate that such \"sharing\" did not happen, or make it undefined behavior if that happens.\r\n\r\nNOTE: the presence of the API is statically known to the compiler, so it would be ok if some runtimes do not have it right away or never. Then optimization will simply not consider 1+ element sizes.\r\n"},"comment":{"url":"https://api.github.com/repos/dotnet/corefx/issues/comments/364004802","html_url":"https://github.com/dotnet/corefx/issues/26948#issuecomment-364004802","issue_url":"https://api.github.com/repos/dotnet/corefx/issues/26948","id":364004802,"user":{"login":"VSadov","id":8218165,"avatar_url":"https://avatars0.githubusercontent.com/u/8218165?v=4","gravatar_id":"","url":"https://api.github.com/users/VSadov","html_url":"https://github.com/VSadov","followers_url":"https://api.github.com/users/VSadov/followers","following_url":"https://api.github.com/users/VSadov/following{/other_user}","gists_url":"https://api.github.com/users/VSadov/gists{/gist_id}","starred_url":"https://api.github.com/users/VSadov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/VSadov/subscriptions","organizations_url":"https://api.github.com/users/VSadov/orgs","repos_url":"https://api.github.com/users/VSadov/repos","events_url":"https://api.github.com/users/VSadov/events{/privacy}","received_events_url":"https://api.github.com/users/VSadov/received_events","type":"User","site_admin":false},"created_at":"2018-02-08T05:13:51Z","updated_at":"2018-02-08T05:13:51Z","author_association":"MEMBER","body":"@alrz - the resulting type does not matter here. From the bigendian point of view we store int32 elements with their bytes in a wrong order. The data will not look like consecutive `1,2,3` on bigendian machine."}}
{"actor":{"display_login":"VSadov"}}