On 09/07/12 02:52, Era Scarecrow wrote:
> On Thursday, 6 September 2012 at 21:58:43 UTC, Artur Skawina wrote:
>> This program won't assert
>> and would segfault if 'i' was accessed by 'func'.
>
> So it seems. The way I read it says it dereferences it first. Regardless
> that you are forcibly referencing a pointer which is low-level trickery;
> which I'm sure is undefined behavior.
There's nothing undefined about passing args by reference; i know the '*s' looks
misleading, but what happens when such an expression is used as a ref arg is
basically '&*s' and then the compiler will let you access the result via the
function parameter; it's essentially syntax sugar (with a few extra usage
restrictions).
> Course if you have to check/treat it as a pointer, adding @safe suddenly
> refuses to compile (Won't let you get the address); But if you leave it out
> (without @trusted either) and make main @safe, suddenly that doesn't compile
> either. (Because I'm sure quite a few functions you'd want to share will end
> up being @safe and pure).
'&ref_arg' not being allowed in @safe mode is indeed a @safe-problem. But it's
not easily fixable right now, because scope enforcement isn't done - so it would
be too easy to leak a reference (pointer). Until it works with @safe, you can do
@safe:
auto func(ref int i) { @trusted check() { assert(!&i); } check(); /*rest of
safe code*/ }
void main() { int* i; func(*i); }
which at least keeps the @trusted part to a minimum. Yeah, it should be possible
to do just '@trusted assert(!&i);', ie have trusted scopes, not just functions;
see
http://www.digitalmars.com/d/archives/digitalmars/D/trusted_considered_harmful_173515.html
.
artur
