The next iteration of scope

Zach the Mystic via Digitalmars-d digitalmars-d at
Wed Mar 18 10:47:23 PDT 2015

On Wednesday, 18 March 2015 at 13:01:50 UTC, Oren Tirosh wrote:
> On Sunday, 15 March 2015 at 19:11:36 UTC, Marc Sch├╝tz wrote:
>> On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote:
>>> On 15/03/2015 14:10, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
>>> <schuetzm at>" wrote:
>>>> Here's the new version of my scope proposal:
>>>> It's still missing real-life examples, a section on the 
>>>> implementation,
>>>> and a more formal specification, as well as a discussion of 
>>>> backwards
>>>> compatibility. But I thought I'd show what I have, so that 
>>>> it can be
>>>> discussed early on.
>>>> I hope it will be more digestible for Walter & Andrei. It's 
>>>> more or less
>>>> an extended version of DIP25, and avoids the need for most 
>>>> explicit
>>>> annotations.
>>> I too want a scope attribute e.g. for safe slicing of static 
>>> arrays, etc. I'm not sure if it's too late for scope by 
>>> default though, perhaps.
>> If we get @safe by default, we automatically get scope by 
>> default, too.
> The scope storage class is a two way contract. The function 
> promises not to escape the reference. The caller promises to 
> ensure the storage that the reference is pointing to will 
> remain valid for the duration of the function call. In some 
> cases, the caller code may need to take active steps to ensure 
> that, like keeping an otherwise temporary reference alive to 
> prevent it from being deallocated.
> But what if the pointer is null? Can this be considered to 
> fulfill the caller's part of the deal?
> Yes, the old @notnull debate again. For me, @safe by default 
> and scope by default also suggests @notnull by default for 
> scope references. Sorry if this opens up directions you don't 
> want to think about at the moment...

So far, null pointers haven't been a big part of the discussion. 
By the existing definition, a null pointer is memory safe, 
because it doesn't point to anything. But they are obviously a 
problem in their own right.

More information about the Digitalmars-d mailing list