{"id":8075,"date":"2017-04-06T14:24:35","date_gmt":"2017-04-06T22:24:35","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vbteam\/?p=8075"},"modified":"2024-07-05T12:36:42","modified_gmt":"2024-07-05T19:36:42","slug":"why-vb2017-only-supports-consuming-ref-returning-methods","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/vbteam\/why-vb2017-only-supports-consuming-ref-returning-methods\/","title":{"rendered":"Why VB2017 only supports consuming ref returning methods"},"content":{"rendered":"

Hi VBers,\nLast week Klaus wrote an amazing post<\/a> detailing a number of improvements made to the Visual Basic IDE and language in Visual Studio 2017 (and he even forgot one, stay tuned for awesome). Regarding the new ref-return feature Jonathan Allen inquired as to why the design was so different from the one in C#. It’s not uncommon for considerations in one language to be different in the other or for the styles of the languages to yield different design decisions, even from the same people. But it’s a great question so I thought I’d write up a longer explanation for the VB design.\nTo put it bluntly, the capabilities around ref-returning method consumption in VB2017 are designed\u00a0to hedge VB\u2019s bets against\u00a0an uncertain future rather than to bring that feature into the mainstream (which it isn’t, even in C#).\nThe #1 scenario for ref returns is array slices–a\u00a0collection type being discussed for the .NET framework which will let you \u2018slice\u2019 off a subset of an array and hand that slice to some other code. We tried an earlier attempt of this with the ArraySegment(Of T) type but it has several drawbacks. Most importantly,\u00a0that its performance isn\u2019t at all comparable to accessing the array element directly. One reason for that is because it requires a lot of copying. So, prior to VS2017 we\u2019d need to write the slice type like this.<\/p>\n

<\/span>structure<\/span> Slice<\/span>(<\/span>of<\/span> T<\/span>)<\/span>\n\u00a0 \u00a0 private<\/span> readonly<\/span> _Array<\/span> as<\/span> T<\/span>(<\/span>)<\/span>\n\u00a0 \u00a0 <\/span>private<\/span> readonly<\/span> _Offset<\/span> as<\/span> integer\n<\/span><\/span>\u00a0 \u00a0 <\/span>sub<\/span> new<\/span>(<\/span>array<\/span> as<\/span> T<\/span>(<\/span>)<\/span>,<\/span> offset<\/span> as<\/span> integer<\/span>)<\/span>\n\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>_Array<\/span> =<\/span> array<\/span>\n\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>_Offset<\/span> =<\/span> offset<\/span>\n\u00a0 \u00a0 <\/span>end<\/span> sub<\/span>\n\u00a0 \u00a0 <\/span>default<\/span> property<\/span> Item<\/span>(<\/span>index<\/span> as<\/span> integer<\/span>)<\/span> as<\/span> T<\/span>\n\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>get<\/span>\n\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>return<\/span> _Array<\/span>(<\/span>_Offset<\/span> +<\/span> index<\/span>)<\/span><\/span>\n\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>end<\/span> get<\/span>\n\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>set<\/span>(<\/span>value<\/span> as<\/span> T<\/span>)<\/span>\n\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>_Array<\/span>(<\/span>_Offset<\/span> +<\/span> index<\/span>)<\/span> =<\/span> value<\/span><\/span>\n\u00a0 \u00a0 <\/span>\u00a0 \u00a0 <\/span>end<\/span> set<\/span>\n\u00a0 \u00a0 <\/span>end<\/span> property<\/span>\nend<\/span> structure<\/span><\/div>\n

 \nThe lines in bold are the problem. The getter\u00a0copies the element at that offsets and returns it. So whatever the size of the element code must pay the cost of copying it. Then the consumer has to copy that value to a local variable. And on the other side if someone wants to write to the array they have to copy the value to call the setter and the setter then copies it again to set the element of the array.\nAlso, because of this difference you can\u2019t modify a member of the element directly if T is a value type. So you couldn\u2019t say (imagine this slice is from an array of points):<\/p>\n

‘ Doesn’t work.<\/span>\nmySlice<\/span>(<\/span>3<\/span>)<\/span>.<\/span>X<\/span> +<\/span>=<\/span> 1<\/span><\/div>\n

 \nThe reason for that is because the value<\/em> returned from mySlice(3) is a copy, not a reference to that element. So modifying it doesn\u2019t really mean anything. So today you\u2019d have to write:<\/p>\n

<\/span>Dim<\/span> temp<\/span> =<\/span> mySlice<\/span>(<\/span>3<\/span>)<\/span>\ntemp<\/span>.<\/span>X<\/span> +<\/span>=<\/span> 1<\/span>\nmySlice<\/span>(<\/span>3<\/span>)<\/span> =<\/span> temp<\/span><\/div>\n

 \nSo, in addition to paying for all the copying I mentioned earlier the indexing operation happens twice;\u00a0once to get the value and once to set it. With a true array this doesn\u2019t happen\u2014there is a single index and the value is modified in place without being copied. These difference may seem small, but in certain high performance applications (*cough* games) the extra overhead is devastating. Enter ref returns. Now a slice default property (or indexer in C#) can be written which directly returns a reference to the underlying array index. That eliminates all of the overhead I just talked about. The index happens only once, and no copying takes place unless<\/em> you store the value of that element in a variable or set that element to a different value. Other than computing the offset that performance is virtually identical to accessing the underlying array directly.\nNow, we haven\u2019t specifically added a slice type to the .NET Framework but it\u2019s something we’re thinking over adding one day. There are other design issues that need to be resolved but this was the very first thing needed to unblock them.\nIf you look at C# this release this one feature pulled in another feature, namely ref locals. There are also considerations around ref locals and decisions like ref re-assignment (making a local \u2018point\u2019 to another location) and whether ref locals are readonly by default and how to specify refness in all of the places a variable can be introduced, differentiating regular assignment from ref assignment, etc. that would all need to be solved in VB as well to enable the same production capabilities. That\u2019s a lot<\/em> of plumbing.\nAnd in VB it would be even more<\/em> plumbing because VB has extra functionality around ByRef such as passing a property ByRef. VB compiler development lead Jared Parsons has a great post detailing the many cases of ByRef in VB<\/a> that explains this. It doesn\u2019t really make any sense to return a property ByRef and handling ByRef in a late-bound context and so the language would work differently for ByRef returns that ByRef parameters (in addition to all the considerations in C#) which is confusing (and<\/em> Jared would have to go update that post with yet more cases).\u00a0That\u2019s a lot<\/em>\u00a0of confusion, syntax, and conceptual overhead to add to VB because C# added a feature that might<\/em> be used to write one collection type someday<\/em>.\nInstead we took a different approach. In short, we implemented just enough<\/em> of the consumption scenario to allow you to do exactly<\/em> with a Slice (or ref returning thing) what you can do with an array and nothing more than that<\/em>. You can assign directly to the array element when you index it but you can\u2019t assign a reference from an array element to a local and assign back into the array later,\u00a0you can modify the value at that index in place, and you can pass that element ByRef but you can\u2019t return it ByRef. This means no new syntax and VB is protected if<\/em> we add slice between VS2017 release and the next version of the language and<\/em> slice becomes the collection type to end all collection types and a million APIs pop up everywhere overnight all returning things ByRef. And if that highly improbable<\/em> nightmare scenario never happens the language bears no scars from it. And that\u2019s why the design is the way it is.\nYou can read the original design notes from last year here<\/a> which briefly say what I\u2019ve said above. But that\u2019s the whole story. Nothing sinister or because VB was thought about at the last minute. It was a tactical decision made to target precisely the scenario for which the ref-return feature was added to\u00a0protect VB users from possibly important consumption scenarios appearing between releases while protecting VB from considerable feature creep of dubious value to its users. Feel free to leave any feedback below or to me directly on Twitter (@ThatVBGuy<\/a>).\nRegards,\nAnthony D. Green<\/strong><\/a>, Program Manager, Visual Basic<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

Hi VBers, Last week Klaus wrote an amazing post detailing a number of improvements made to the Visual Basic IDE and language in Visual Studio 2017 (and he even forgot one, stay tuned for awesome). Regarding the new ref-return feature Jonathan Allen inquired as to why the design was so different from the one in […]<\/p>\n","protected":false},"author":258,"featured_media":8818,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7,195],"tags":[],"class_list":["post-8075","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-language-design","category-visual-basic"],"acf":[],"blog_post_summary":"

Hi VBers, Last week Klaus wrote an amazing post detailing a number of improvements made to the Visual Basic IDE and language in Visual Studio 2017 (and he even forgot one, stay tuned for awesome). Regarding the new ref-return feature Jonathan Allen inquired as to why the design was so different from the one in […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/posts\/8075","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/users\/258"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/comments?post=8075"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/posts\/8075\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/media\/8818"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/media?parent=8075"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/categories?post=8075"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/vbteam\/wp-json\/wp\/v2\/tags?post=8075"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}