ref parameters: there is no escape
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sun Aug 14 10:06:10 PDT 2011
On 8/14/11 12:02 PM, dsimcha wrote:
> On 8/14/2011 12:54 PM, Andrei Alexandrescu wrote:
>> I have only little sympathy for this argument; it actually leaves me
>> more convinced we're on the right path. We're not talking about making
>> it impossible to do something that you want to do. We're discussing
>> about a change that will make a lot of functions efficient _and_ safe,
>> leaving a minority of cases to a slight syntactic change.
>>
>>
>> Andrei
>
> But this breaks encapsulation horribly in the presence of conservative
> rules. Let's say you start off with a function:
>
> SomeType fun(ref T arg) { .... }
>
> Then you change fun()'s implementation such that it takes the address of
> arg. It does **not** escape this address, so the fact that the address
> is taken is an implementation detail. However, since the compiler's
> rules are conservative, this code would might be illegal if the compiler
> can't prove via its static analysis that the addresses don't escape.
> Bam! Implementation details leaking into function signatures.
You are exploring an increasingly narrow niche. Is it worth keeping a
hole in the language for the sake of that?
Andrei
More information about the Digitalmars-d
mailing list