On 11 May 2012 11:24, kenji hara <k.hara.pg@gmail.com> wrote:
Just before the release of 2.059, I implemented the behavior to avoid
breaking of existing codes for only struct literals. I didn't support
other rvalues with it, like such ternary expression. It was minimum
hack.
I think it is a special behavior of 2.059, and I've been highly
skeptical to leave it up to the future, even if changing it breaks
existing codes.
I also think that a need of 'auto ref stroage class for non-template
function parameter' is increasing.
Yeah, I've run into a need for 'auto ref' a few times now actually, and I've also been running into these lvalue->ref problems all week.
What are the odds that full const ref support might be fleshed out some time soon? We're having to implement quite a few work around for it...
This problem has gotten me thinking though, should ref just be a proper storage class? (why isn't it?)
It seems that would address almost all problems with it immediately.
- There are also some syntactical issues/ambiguities that ref(type) would solve.
- You'd be able to declare ref locals (which would be super useful)
- 'auto' would work, no need to special case said 'ref auto', which seems a but nasty, in generic code you might not always want that... It'll only be a matter of days before someone wants a 'true' auto.
- Solve these recently discussed issues where you can't describe a function/delegate that returns by ref without piping it through an alias.
All ref should really be, is syntactical sugar for a pointer, which asserts that it be non-null/initialised, and that it not expose the pointer assignment mechanism.
Is there something more that 'ref' does in D that wouldn't work under that setup?