Const ref and rvalues again...

[Jonathan M Davis]

On Friday, November 09, 2012 10:33:45 Manu wrote:
> On 9 November 2012 00:44, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Thursday, November 08, 2012 21:49:58 Manu wrote:
> > > That's cute, but it really feels like a hack.
> > > All of a sudden the debugger doesn't work properly anymore, you need to
> > > step-in twice to enter the function, and it's particularly inefficient
> > > in
> > > debug builds (a point of great concern for my industry!).
> > > 
> > > Please just with the compiler creating a temporary in the caller space.
> > > Restrict is to const ref, or better, in ref (scope seems particularly
> > > important here).
> > 
> > I honestly wish that in didn't exist in the language. The fact that it
> > it's an
> > alias two different attributes is confusing, and people keep using it
> > without
> > realizing what they're getting into.
> 
> I understand it's an alias for 'const scope', but what's this about scope
> not working correctly? What's wrong with it?
> It seems like precisely what you want in this case... you don't want a
> temporary escaping the function you pass it to.
> What's the problem?

It only works with delegates. In all other cases, it's ignored.

> If scope worked correctly, you'd only
> 
> > want it in specific circumstances, not in general. And since it doesn't
> > work
> > correctly aside from delegates, once it _does_ work correctly, it'll break
> > code all over the place, because people keep using in, because they like
> > how
> > it corresponds with out or whatever.
> 
> I like how it promises that the thing I pass can't escape the callee, not
> that it's the natural english compliment to 'out'.

There are cases where it's useful, but there are a ton of cases where it would 
be really annoying if it worked properly. For instance, in a _lot_ of cases, 
it would cause problems for a function taking an array, because it couldn't 
return a slice of the array. Any struct holding any reference types would be 
in the same boat, as would any class or AA.

In most cases, it really doesn't matter whether references escape, because the 
stuff is on the GC heap, and it'll collect it when it's appropriate. It would 
be a much bigger deal if you had to worry about ownership.

For delegates, it's great because it allows you to avoid allocating a closure, 
so if you don't need the delegate to escape, it makes perfect sense to make it 
scope. For everything else, whether it makes sense depends on what you're 
doing, and sometimes it would be useful, but most of the time, it really 
wouldn't be.

But since in currently only works for delegates, it's absolutely pointless to 
use it instead of const for anything else, and if/when scope is ever fixed to 
work with reference types in general, then all kinds of code that uses in will 
break, because it'll be escaping references, and the programmer didn't notice 
it. So, you might as well just not use it at this point except for delegates.

Regardless, you don't need in to use scope. You can just use scope directly. 
So, having in buys you _nothing_, and it unfortunately encourages people to 
use it (which IMHO is bad due to the issues with scope), because they like how 
it's the opposite of out. So, if we didn't have in, we'd be able to do exactly 
what we can do now, but people wouldn't be using scope all over the place via 
in just because they liked the idea of in being the opposite of out.

But originally, in comes from D1 (where it had a meaning similar to const 
IIRC, but scope had nothing to do with it), so it's been around for a long 
time, and there's pretty much no way that it would be removed from the 
language. I just think that it was mistake to have it given its current 
semantics. It's also a bit pointless IMHO to have an attribute which is an 
alias for other attributes. It's a needless duplication of functionality and 
just increases confusion.

- Jonathan M Davis