<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 February 2014 09:16, Adam D. Ruppe <span dir="ltr"><<a href="mailto:destructionator@gmail.com" target="_blank">destructionator@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, 5 February 2014 at 22:32:52 UTC, Andrei Alexandrescu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the face of it it seems odd that reference counted chunks of typed memory are deemed useless<br>
</blockquote>
<br>
I don't think anybody has actually said that. They have their places, it is just useless to talk about throwing them in everywhere.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I should also add that imparting useful semantics to scope is much more difficult than it might seem.<br>
</blockquote>
<br>
I'm not so sure about that*, but the fact is scope would be enormously useful if it was implemented.<br>
<br>
* Let's say it meant "assigning to any higher scope is prohibited". That should be trivially easy to check and ensures that variable itself doesn't escape. The tricky part would be preventing:<br>
<br>
int[] global;<br>
void foo(scope int[] a) {<br>
   int[] b = a;<br>
   global = b;<br>
}<br>
<br>
<br>
And that's easy to fix too: make ALL variables scope, unless specifically marked otherwise at the type declaration site (or if they are value types OR references to immutable data, which are very similar to value types in use).<br>
</blockquote><div><br></div><div>Surely a simpler solution is to mark b scope too? Does that break-down at some point?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The type declaration can be marked as a reference encapsulation and those are allowed to be passed up (if the type otherwise allows; e.g. postblit is not disabled).<br>
<br>
That would break a fair chunk of existing code**, but it'd make memory management explicit, correct, and user extensible.<br>
<br>
** I think moving to not null by default at the same time would be good, just rip off teh whole band aid.<br>
</blockquote></div><br></div></div>