On Friday, November 09, 2012 10:33:45 Manu wrote:
> On 9 November 2012 00:44, Jonathan M Davis <jmdavisProg@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.

Does that actually make sense? Surely a function that receives a scope argument can return that argument, since it's only passing it back to the same function that already owns it... it knows it can trust that function, since it was received from that function.

Any struct holding any reference types would be
in the same boat, as would any class or AA.

I don't follow the problem with reference args. surely they can be evaluated just fine? Just that nothing can escape the function...

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.

It's true, and stack locals are perhaps the most important thing that scope could possibly protect... which makes it particularly applicable here.

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.

Of course, and whether you apply the scope attribute to a function argument equally depends on what you're doing :)

I still can't see any inherent problems from what you're saying. It's still just an access restriction to enhance safety.

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.

Very good point. I had no idea it didn't work. It'd be nice to see this fixed.

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.

The issue here is that 'scope' is an incomplete feature. I think it's theoretically sound.

Every conversation/thing I've read on the topic certainly gave me the impression it worked...

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.

Oh really? That's not at all what I had imagined. I presumed 'in' was invented when it was realised that 'const scope' was a super-common pattern.

I still don't see any less value in it. Just that it should work properly.

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.

Side topic: what I find myself constantly wanting is alias for attributes!
Especially when dealing with GDC/LDC which have their own non-standard attributes. I'm often wanting to create a meaning alias for the set of attributes applicable to my code.

And you can't currently use GDC attributes without static if and physically duplicating all the attributed code >_<