@safe leak fix?

Steven Schveighoffer schveiguy at yahoo.com
Fri Nov 13 06:23:01 PST 2009


On Fri, 13 Nov 2009 08:31:07 -0500, Jason House  
<jason.james.house at gmail.com> wrote:

> Steven Schveighoffer Wrote:
>
>> So the signature of strstr has to be unmarked (no @safe or @trusted).
>
> I disagree. Borrowing the syntax from the return const proposal, let's  
> define strstr as follows:
> inout(char[]) strstr(inout(char[]) buf, const(char[]) orig);
>
> What I want that to tell the compiler is that buf, or some piece of buf,  
> is returned from strstr. (please don't assign any more meaning than  
> that, i.e. constness of buf). The compiler would then treat the return  
> value with the same protection as buf, and a return without .dup is a  
> compile error.
>
> I've been in drawn out discussions with you before. If this post and my  
> prior post don't make you budge from your position than I'll simply give  
> up trying to convince you. It's not worth the aggregation.

Sure, we can stop discussing.  I'll just say I think the escape analysis  
problem is more complicated than the scoped const problem.  Simply  
because, scoped parameters are not necessarily non-mutable, whereas scoped  
const parameters are always treated as const.  scoped const has one output  
(the return value) and N inputs.  escape analysis has N inputs and M  
outputs.  Annotation is going to be very hard for functions like swap.   
Simplifications are possible, but like I said, conservative line in the  
sand.

-Steve



More information about the Digitalmars-d mailing list