alias ref int rint;
rint foo() { static int x; return x; }
void main()
{
auto p = &(foo());
}
This doesn't work. It led me to write the ugliest code I have ever written. Search std.range for "mixin" if you want to see ugly stuff.
Comment #1 by kamm-removethis — 2009-04-30T02:40:48Z
I'm not sure allowing that alias is a good idea, as ref int and int still name the same type. If that alias worked, wouldn't you expect
alias ref int rint;
int i = 3;
rint ri = i;
ri = 4;
assert(i == 4);
Comment #2 by andrei — 2009-04-30T08:12:47Z
(In reply to comment #1)
> I'm not sure allowing that alias is a good idea, as ref int and int still name
> the same type. If that alias worked, wouldn't you expect
>
> alias ref int rint;
> int i = 3;
> rint ri = i;
> ri = 4;
> assert(i == 4);
>
The ref would be only effective in a function signature. This can be done (I discussed it with Walter). The problem is, Walter has a lot on his plate already. Yet that doesn't make my code look any better :o).
Comment #3 by dfj1esp02 — 2009-05-04T08:44:11Z
dup of bug 2753?
Comment #4 by andrej.mitrovich — 2012-12-23T10:45:12Z
(In reply to comment #2)
> (In reply to comment #1)
> > I'm not sure allowing that alias is a good idea, as ref int and int still name
> > the same type. If that alias worked, wouldn't you expect
> >
> > alias ref int rint;
> > int i = 3;
> > rint ri = i;
> > ri = 4;
> > assert(i == 4);
> >
>
> The ref would be only effective in a function signature.
So would that code error at compile-time or just silently compile and fail at runtime as if the ref didn't exist? It's tricky business..
But there's definitely a problem of not being able to pass around 'ref' in metaprogramming. The classic example being std.signal, where you can't define a signal with ref parameters:
struct S
{
// would allow connecting to 'void f(ref int) { }'
mixin Signal!(ref int);
}