On Friday, June 28, 2013 13:55:45 Adam D. Ruppe wrote:
> On Friday, 28 June 2013 at 07:07:39 UTC, Marco Leise wrote:
> > Isn't that what scope is for?
> 
> I don't really know. In practice, it does something else (usually nothing, but suppresses heap closure allocation on delegates). The DIPs relating to it all talk about returning refs from functions and I'm not sure if they relate to the built ins or not- I don't think it would quite work for what I have in mind.

Per the spec, all scope is supposed to do is prevent references in a parameter to be escaped. To be specific, it says

-------
ref­er­ences in the pa­ra­me­ter can­not be es­caped (e.g. as­signed to a global vari­able)
-------

So, in theory, if you had something like

auto foo(scope int[] i) {...}

it would prevent i or anything refering to it from being returned or assigned to any variable which will outlive the function call. However, scope currently does _nothing_ for anything other than delegates - which is why I think that using the in attribute is such an incredibly bad idea. Using either in or scope on anything other than delegates could result in all kinds of code breakage if/when scope is ever implemented for types other than delegates.

For delegates, it has the advantage of telling the compiler that it doesn't need to allocate a closure (since the delegate won't be used passed the point when it's calling scope will exist as could occur if the delegate escaped the function it was passed to), but I'm not sure that even that works 100% correctly right now.

We really should sort out exactly what we're going to do with scope one of these days soon.

But the stuff that some of the DIPS do with scope (e.g. returning with scope - which is completely against the spec at this point) are suggestions and not at all how it currently works.

- Jonathan M Davis

On Friday, 28 June 2013 at 17:43:21 UTC, Jonathan M Davis wrote:
> it would prevent i or anything refering to it from being returned or assigned to any variable which will outlive the
> function call. However,

That's fairly close to what I'd want. But there's two cases I'm not sure it would cover:

1:

struct Unique(T) {
   scope T borrow();
}

If the unique pointer decides to let its reference slip, it wouldn't want it going somewhere else and escaping, since that breaks the unique need.

This is important for a few cases. Here's one:

  int* foo;
  {
     Unique!(int*) bar;
     foo = bar.borrow;

     int* ok = bar.borrow; // this should be ok, because this never exists outside the same scope as the Unique
  }

  // foo now talks to a freed *bar, so that shouldn't be allowed

Similarly, if bar were reassigned, this could cause trouble, but what we might do is just disallow such reassignments, but maybe it could work if it always goes down in scope. I'd have to think about that.


(I'm thinking my borrowed thing might have to be a type constructor rather than a storage class. Otherwise, you could get around it by:

int* bar(scope int* foo) {
  int* b = foo;
  return b;
}

Unless the compiler is very smart about following where it goes.)


But if scope works on the return value too, it might be ok.


maybe 2:

void bar(scope int* foo, int** bar) {
    *bar = foo;
}


Actually, I'm reasonably clear the spec's scope words would work for this one. But we'd need to be sure - this is one case where pure wouldn't help (pure generally would help, since it disallows assignments to the outside world, but there's enough holes that you could leak a reference).


To be memory safe, these would all have to be guaranteed.

On Friday, June 28, 2013 19:56:44 Adam D. Ruppe wrote:
> struct Unique(T) {
> scope T borrow();
> }

Per the current spec, this would not be a valid use of scope, as scope is specifically a parameter storage class and can only be used on function parameters (just like in, out, ref, and lazy). scope seems to be specifically intended for guaranteeing that an argument passed to a function does not escape that function.

- Jonathan M Davis

On Wednesday, 26 June 2013 at 13:16:25 UTC, Jason House wrote:
> Bloomberg released an STL alternative called BSL which contains an alternate allocator model. In a nutshell object supporting custom allocators can optionally take an allocator pointer as an argument. Containers will save the pointer and use it for all their allocations. It seems simple enough and does not embed the allocator in the type.
>
> https://github.com/bloomberg/bsl/wiki/BDE-Allocator-model

There is also EASTL's (Electronic Arts version of STL for gamedev) take on allocators.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#eastl_allocator