On 11 May 2012 11:24, kenji hara <[email protected]> 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?
