RFC: scope and borrowing

[via Digitalmars-d]

On Monday, 25 August 2014 at 18:14:03 UTC, Marc Schütz wrote:
> But this would require knowledge about the inner workings of 
> memset() to be part of the IR, or memset() to be implemented in 
> it.

The latter. You might have "zerofill(ptr,length)" and turn it 
into "clear(data)" if it is @safe.

> The same IR (or an equivalent one) would then need to be part 
> of language specification, otherwise different compilers would 
> allow different operations.

I think you could have a low performance minimum requirement 
reference implementation for this between the front-end and the 
back-end.

As in, not written for performance, but as a baseline for testing 
the real implementation.

> currently, blacklist approach). If something has been 
> overlooked, it can be added incrementally; at the same time 
> there's always @trusted to let the programmer specify what the 
> compiler can't prove.

I think borrow, @safe and other types of correctness oriented 
analysis aspects should be seen as two aspects of the same thing. 
So it is desirable to design it as a whole IMO.

Especially if assert() is going to turn into assume(). Which I 
believe will only work reliably for preconditions on a code-scope 
up to the postconditions, but I believe you need some heavy duty 
analysis of the call-chain to get anywhere.

I presume you can do the same for allocations between 
preconditions and postconditions and that could let you establish 
@safe for a wider range of constructs this way.

I.e. the work on assert->assume for preconditions could lead to a 
wider range of @safe and also perhaps automatic memory allocation 
optimizations.

It sounds reasonable that constraining the input sometimes would 
give information that could help on establishing @safe on code 
that would otherwise have to be assume unsafe.

Ola.