Escape analysis (full scope analysis proposal)

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> BTW, slightly OT, I read Bartosz' article on digitalmars about SafeD. 
>> This isn't an implemented language right?  Is the plan for D to become 
>> SafeD?  Or is there going to be a compiler switch?  Or something else 
>> maybe?  I've heard SafeD mentioned a lot on this NG, without ever really 
>> knowing how it exists (concrete or theory).
>
> It's planned as a compiler switch and module option. Essentially SafeD is 
> slated to be a safe, proper, well-defined subset of D. It was Bartosz's 
> idea, and IMHO an important dimension of D's development.

I personally probably won't use it, as I feel I have enough experience to 
avoid the problems that SafeD will prevent.  But it does sound like a very 
important version of the language.

> Walter is implementing module safety options like this:
>
> module(safe) mymodule;
>
> which means the module must always be compiled with safety on. On the 
> contrary,
>
> module(system) mymodule;
>
> means the module is getting its hands greasy.

Hm... that's kinda too high level.  I might have one function in a class 
that does things that are 'unsafe', but I don't want to have to mark my 
whole class as unsafe.

>>> * For delegates require the scope keyword in the signature of the 
>>> callee. A scoped delegate cannot be stored, only called or passed down 
>>> to another function that in turn takes a scoped delegate. This makes 
>>> scope delegates entirely safe. Non-scoped delegates use dynamic 
>>> allocation.
>>
>> If noscope (or equivalent keyword) is used, can we make scope the 
>> default? I'd much rather have the default be the higher-performance, more 
>> commonly used option.
>
> I think safety should be the default. People who care about efficiency 
> will be willing to write a little bit more. I agree that this is annoying 
> if that's the more frequent situation.

What I meant was, make the default behavior as if scope was marked on the 
delegate.  This doesn't make it unsafe (you said so yourself).  But it does 
line up with most code today, which doesn't do anything with a delegate but 
call it.  i.e. less decorations on current code that is already considered 
safe.

The most obvious usage is opApply.  Every opApply will have to have its 
delegate marked scope unless it's the default.

The only downside is that you then have to come up with a way to mark a 
delegate as noscope.

>> Also, when you say stored, do you mean stored anywhere, or stored 
>> anywhere but the stack?  Because there is no harm in storing a scope 
>> delegate in a local variable (as long as it is also scope).
>
> That could be allowed, but probably it's not really needed.

I can think of certain cases to need it, for example if you have two inner 
functions that have the same signature, and you want to decide which one to 
use at runtime, you might store the one to use in a local variable.

---------------------------

It seems to me like the way you are saying things will work is that you will 
have either safety checks or no safety checks at a module level.  I think 
that is a mistake.  Most of my code should be safe, and I'd prefer it to be 
safety checked.  The ideas that all of you have come up with in this post 
are very good, and should be easy to use for most code.  I especially like 
the requirement to cast in order to take the address of a reference.  But if 
all those checks go away when you mark your module as system, then this 
seems like it will either require me to split up my modules into safe and 
unsafe parts, or just not use safety checks where they could be used.  I'd 
prefer to be able to mark specific functions/parameters as unsafe or safe so 
I know exactly where I have disabled the safety checks.

And I'd prefer safety by default, not have to mark for safety.  As long as 
the safety can be easily verified and allows most usages.  I really like how 
pointers are simply considered unsafe, so all safety checks are off.  That 
draws a clear line of where it's difficult to verify safety without 
hindering ability.  The further check of compliance to SafeD can eliminate 
possible pointer usages that you miss.

-Steve