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